FR2888698A1 - Dispositif de communication, procede de formation d'un message de protocole de transfort et procede de traitement d'un message de protocole de transport - Google Patents
Dispositif de communication, procede de formation d'un message de protocole de transfort et procede de traitement d'un message de protocole de transport Download PDFInfo
- Publication number
- FR2888698A1 FR2888698A1 FR0605234A FR0605234A FR2888698A1 FR 2888698 A1 FR2888698 A1 FR 2888698A1 FR 0605234 A FR0605234 A FR 0605234A FR 0605234 A FR0605234 A FR 0605234A FR 2888698 A1 FR2888698 A1 FR 2888698A1
- Authority
- FR
- France
- Prior art keywords
- transport protocol
- data
- unit
- source
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 114
- 238000012545 processing Methods 0.000 title claims abstract description 39
- 238000000034 method Methods 0.000 title claims description 30
- 238000012546 transfer Methods 0.000 claims description 4
- 108010001267 Protein Subunits Proteins 0.000 claims 1
- 230000005540 biological transmission Effects 0.000 abstract description 20
- 238000010295 mobile communication Methods 0.000 description 25
- 230000001276 controlling effect Effects 0.000 description 10
- 230000000694 effects Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 230000005355 Hall effect Effects 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 108700026140 MAC combination Proteins 0.000 description 2
- 230000004913 activation Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 230000009849 deactivation Effects 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000001105 regulatory effect Effects 0.000 description 2
- 230000001755 vocal effect Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000004886 process control Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un dispositif de communication comporte une unité (202) de codage à la source ainsi qu'une unité (203) de protocole de transport. L'unité (203) de protocole de transport est conçue de façon à pouvoir ajouter aux données codées à la source dans le message de protocole de transport une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport.
Description
Dispositif de communication, procédé de formation d'un message de
protocole de transport et procédé de traitement d'un message de protocole de transport
L'invention concerne un dispositif de communication ainsi qu'un procédé de formation d'un message de protocole de transport et un procédé de traitement d'un message de protocole de transport.
Dans le cadre d'une liaison de communication établie entre deux dispositifs de communication, par exemple dans le cadre d'une conversation téléphonique, des signaux audio sont habituellement échangés en temps réel entre un dispositif de communication émetteur (désigné habituellement par source dans la technique de communications) et un dispositif de communication récepteur (désigné habituellement par récepteur dans la technique de communication).
Habituellement, le dispositif de communication émetteur n'a alors aucune possibilité d'influer, de façon ciblée quelconque, sur la manipulation des données reçues en temps réel (par exemple sur le traitement des signaux audio reçus, par exemple pour délivrer les signaux audio) dans le dispositif de communication récepteur.
Le document [1] enseigne ce que l'on appelle le Real time Transport Protocol (RTP) qui est employé pour la transmission de données en temps réel en utilisant les protocoles Internet Transport Control Protocol (TCP) et Internet Protocol (IP) et qui est employé habituellement avec ce que l'on appelle Real time Transport Control Protocol (RTCP).
Dans le cadre du RTP, la définition de profils pour différentes classes de données utiles est possible, par exemple comme le RTP Profile for Audio and Video Conferences selon le document [2].
Les principes de base de l'Internet Protocol (IP) Multimedia Core Network Subsystem ainsi que le IP Multimedia Subsystem (IMS) lui-même sont enseignés dans les documents [3] respectivement [4].
En outre, il est enseigné dans le document [5] d'influer sur le niveau ou sur la courbe de niveau d'un signal acoustique utile. Selon le document [5], on génère du côté de l'entrée une information de régulation qui est transmise parallèlement au signal utile, l'information étant compressée conjointement avec le signal utile dans un codeur et transmise au récepteur, l'information de régulation étant extraite du côté du récepteur par le décodeur afin de commander la reproduction du signal utile.
L'inconvénient de ce mode opératoire est par exemple qu'il faut modifier entièrement le codeur et le décodeur lors de la modification du type de l'information de commande qui est codée et transmise conjointement avec le signal utile.
Cela prend du temps et très onéreux. Dans le cas où le codeur et le décodeur sont conformés en composants matériels, il faut remplacer les deux composants matériels dans la source dans le récepteur.
Dans le document [6], il est décrit un système d'encapsulation d'informations de commande dans un flux de données en temps réel. Il est alors prévu un compresseur qui évite la transmission redondante d'informations RTP/UDP/IPHeader et qui permet d'obtenir ainsi un Overhead plus faible lors de la transmission de données.
Le but de l'invention est de proposer des dispositifs de communication et un procédé de formation respectivement de traitement d'un message de protocole de transport qui permettent de façon plus souple et moins onéreuse de faire évoluer respectivement de modifier l'information de commande de données utiles.
Le but est atteint par les dispositifs de communication, le procédé de formation d'un message de protocole de transport ainsi que le procédé de traitement d'un message de protocole de transport présentant les caractéristiques suivantes.
Un dispositif de communication comporte une unité de codage à la source destinée à coder à la source des données à transmettre ainsi qu'une unité de protocole de transport couplée à l'unité de codage à la source et destinée à générer au moins un message de protocole de transport à partir des données codées à la source. L'unité de protocole de transport est conçue de façon à pouvoir ajouter aux données codées à la source dans le message de protocole de transport une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport.
Dans un autre aspect de l'invention, il est prévu un dispositif de communication comportant une unité de protocole de transport destinée à former des données codées à la source à partir d'au moins un message de protocole de transport reçu ainsi qu'une unité de décodage à la source couplée à l'unité de protocole de transport et destinée à décoder à la source les données codées à la source. L'unité de protocole de transport est conçue de façon à pouvoir déterminer à partir du message de protocole de transport une information de commande permettant de commander le traitement des données codées à la source et/ou décodée la source. En plus ou en variante, l'unité de décodage à la source peut également être conformée de façon à pouvoir influer totalement ou partiellement sur le processus de décodage lui-même avec l'information de commande (une partie de l'information de commande) déterminée à partir du message de protocole de transport. En outre, il est prévu une unité de traitement qui est conçue de façon à pouvoir traiter les données codées à la source et/ou décodée à la source conformément à l'information de commande déterminée.
Un procédé de formation d'un message de protocole de transport comporte les étapes suivantes dans lesquelles: - les données utiles à transmettre sont codées à la source, - un message de protocole de transport est formé à partir des données décodées à la source conformément un protocole de transport.
Dans le message de protocole de transport, il est ajouté une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport (avant, pendant ou après le décodage).
L'ajout de l'information de commande peut alors être effectué aussi bien en fonction de l'allure dans le temps des données utiles qu'en fonction du contenu des données utiles pour établir du côté de l'émetteur des rapports entre l'information de commande et les données utiles. De façon analogue, le rapport établi du côté de l'émetteur (par exemple en fonction du temps ou du contenu) entre l'information de commande et les données peut encore être établi du côté du récepteur.
Dans un autre aspect de l'invention, il est proposé un procédé de traitement d'un message de protocole de transport dans lequel des données codées à la source sont générées à partir d'au moins un message de protocole de transport reçu, conformément un protocole de transport. En outre, on détermine à partir du message de protocole de transport une information de commande permettant de commander le traitement des données codées à la source et/ou décodée à la source ou de commander le processus de décodage lui-même.
Dans le cadre de cette description, on entend par unité de codage à la source une unité qui compresse un ensemble de données ou flux de données non compressés (par exemple un flux de données de type vidéo, audio ou texte) conformément à un algorithme prescrit dans le but de réduire le caractère redondant et/ou insignifiant (deux approches généralement connus de réduction de la quantité de données par la technique de communication). La réduction de la redondance prend en compte des propriétés de la source dans le but de réduire la quantité de données à transmettre. Dans le cas du codage vidéo, on utilise par exemple des propriétés statistiques d'un signal d'image, par exemple la corrélation entre des points d'image adjacents dans le temps et dans l'espace pour générer un code le plus compact possible. La réduction du caractère insignifiant a pour but d'omettre dans la transmission l'information qui n'est pas importante pour la réception. Cela signifie concrètement par exemple dans le cas du codage vidéo que seule une partie des données d'image est transmise. On autorise alors les distorsions ainsi générées qui perturbe le moins possible l'observateur humain. De façon correspondante, dans le cadre de cette description, on entend par unité de décodage à la source une unité qui décompresse un flux de données ou ensemble de données compressés (par exemple un flux de données ou ensemble de données de type vidéo, audio ou texte) selon un algorithme prescrit.
On utilise dans la suite le terme Codec pour l'ensemble constitué par une unité de codage à la source et une unité de décodage à la source, une unité constituée d'un compresseur ou d'un décompresseur respectivement d'un codeur ou d'un décodeur étant désignée concrètement par le terme Codec.
Il faut cependant mentionner que, dans le cas où il est prévu une communication unidirectionnelle, il peut également être prévu théoriquement dans un dispositif de communication une seule unité de codage à la source ou une seule unité de décodage à la source. Lors de la compression, on détermine habituellement dans quel format de fichier le matériau fini, c'est-à-dire l'ensemble de données ou flux de données compressés sera converti, c'est-à-dire que des fichiers du même format de fichier ne doivent pas obligatoirement être compressés avec le même Codec (algorithme).
Un Codec, aussi bien comme unité de codage à la source que comme unité de décodage à la source, peut exister séparément sous la forme d'un matériel séparé, c'est-à-dire au moyen d'un circuit électronique spécial (HardwareCodec) ou sous la forme d'un programme informatique, c'est-à-dire un logiciel (désigné dans la suite par exemple par Soft-Codec).
En raison du fait que la puissance des processeurs actuels a fortement augmenté ces dernières années, par exemple dans le domaine des terminaux de télécommunications mobiles, de nombreux procédés de compression en temps réel peuvent être mis en uvre actuellement sur des processeurs correspondant à l'aide d'un Soft-Codec. L'utilisation d'un Soft-Codec présente l'avantage de ne plus nécessiter de circuits électroniques spéciaux, c'est-à-dire de matériels spéciaux, ce qui permetdes solutions très bon marché. En outre, les solutions Soft-Codec ont un avenir plus sûr car les mises à jour ultérieures de logiciel, c'est-à-dire l'actualisation ultérieure du Soft-Codec, peuvent être réalisées très simplement et donc à bon marché.
Dans le cadre de cette description, il faut entendre par unité de protocole de transport une unité qui forme des messages dans un protocole de transport conformément à un modèle de couches de communication, par exemple conformément à au modèle de couche de communication OSI (OSI: Open System Interconnection).
En résumé, selon un aspect de l'invention, au niveau de la couche protocole de transport, on ajoute à des données codées à la source, à transmettre, une information de commande permettant de commander du côté de l'émetteur le traitement (par exemple la délivrance ou la mémorisation des données à transmettre) respectivement d'extraire, au niveau de la couche protocole de transport du côté du récepteur, des informations de commande permettant de commander le traitement (par exemple la mémorisation des données codées à la source avant le décodage, le processus de décodage lui-même et/ou la représentation des données codées à la source après le décodage dans le dispositif de communication récepteur).
Un avantage considérable de l'invention est que l'ajout de l'information de commande n'est plus effectué dans le Codec lui-même mais au sens d'un modèle de couche de communication au-dessous de la couche d'application Codec, c'est-à-dire dans la couche de transport de sorte qu'une actualisation et modification très simples de l'information de commande à transmettre est possible sans nécessiter de modifier le Codec lui-même et donc l'unité de codage à la source respectivement l'unité de décodage à la source. Ainsi, on obtient une économie et flexibilisation considérables des dispositifs de communication, ce qui est très avantageux notamment dans le domaine des dispositifs de communication par téléphonie mobile.
Des conformations préférées de l'invention sont les suivantes. Les conformations des dispositifs de communication sont valables aussi bien pour le procédé de formation d'un message de protocole de transport que pour le procédé de traitement d'un message de protocole de transport.
L'unité de protocole de transport peut contenir des unités dans lesquelles coopèrent plusieurs unités de protocole de transport ayant différents protocoles de transport. L'unité de protocole de transport peut ainsi comporter par exemple une première sous-unité de protocole de transport et une deuxième sous-unité de protocole de transport. La deuxième sous-unité de protocole de transport est destinée à former un message à partir du message formé par la première sous-unité de protocole de transport conformément par exemple au Transport Control Protocol (TCP) ou au User Datagram Protocol (UDP). La première sous-unité de protocole de transport a pour but, dans cette conformation de l'invention, de pouvoir ajouter aux données codées à la source dans le message de protocole de transport une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport.
Concrètement, dans cette conformation de l'invention, il est prévu une sous-couche de protocole de transport qui est destinée à coder les données à transmettre dans laquelle on ajoute l'information de commande. Cette sous-couche de protocole de transport est concrètement placé au sens du modèle de couche de communication au-dessus de la deuxième sous- couche de protocole de transport, par exemple TCP ou UDP, de sorte que les données formées par la première sous-unité de protocole de transport sont empaquetées dans des messages TCP ou des messages UDP, c'est-à-dire dans des paquets de données correspondants.
La première sous-unité de protocole de transport est destinée, dans une conformation de l'invention, à former au moins un message à partir des données codées à la source conformément à l'un des protocoles de communication suivants: - Real Time Transport Protocol (RTP) - Real Time Transport Control Protocol (RTCP), ou - Hypertext Transfer Protocol (HTTP) .
Notamment, lors du transfert de données en temps réel, par exemple de signaux vidéo ou de signaux audio, c'est-à-dire de données qui doivent être représentées en temps réel au niveau du récepteur, il est particulièrement avantageux d'utiliser un protocole de transport garantissant la transmission de données en temps réel, par exemple le RTP ou le RTCP commandant le RTP.
D'une façon générale, il peut être prévu tout protocole de transport quelconque pour recevoir dans l'unité de réception l'information de commande destinée au traitement des données à transmettre.
La première sous-unité de protocole de transport est destinée, dans une conformation de l'invention, à introduire l'information de commande dans la zone d'en-tête du message de protocole de transport.
Dans une autre conformation de l'invention, il est prévu que la première sous-unité de protocole de transport soit destinée à introduire l'information de commande dans la zone de champ de données utiles du message de protocole de transport.
Dans un aspect de l'invention, l'information de commande permet de commander le type de délivrance d'information audio sous la forme de données à transmettre, par exemple le volume ou l'ajout, l'activation ou la désactivation d'effets sonores supplémentaires.
En variante ou en complément, dans une conformation de l'invention, l'information de commande peut commander une mémorisation d'une partie des données à transmettre, ce qui permet par exemple de mémoriser temporairement ou durablement une partie prescrite, par exemple dans un flux de données vidéo (ou dans un flux de données audio), de sorte que le récepteur peut reproduire cette information à un moment ultérieur, éventuellement même avec un autre terminal qui est en mesure de reproduire l'information audio ou l'information vidéo.
Dans une conformation du dispositif de communication recevant les données à transmettre, il est prévu que l'unité de protocole de transport comporte une première sous-unité de protocole de transport et une deuxième sous-unité de protocole de transport, la deuxième sous-unité de protocole de transport étant destinée à former au moins un message pour la première sous-unité de protocole de transport à partir d'un message reçu conformément au Transport Control Protocol ou au User Datagram Protocol. L'unité de protocole de transport est destinée à déterminer à partir du message de protocole de transport une information de commande permettant de commander le traitement par exemple des données codées à la source.
La première sous-unité de protocole de transport peut être destinée à coder un message conformément à l'un des protocoles de communication suivants: - Real Time Transport Protocol (RTP) - Real Time Transport Control Protocol (RTCP), ou - Hypertext Transfer Protocol (HTTP).
Les données à transmettre sont par exemple des données en temps réel, auquel cas il est prévu par exemple d'utiliser le RTP et/ou le RTCP.
La première sous-unité de protocole de transport peut être destinée à déterminer l'information de commande à partir de la zone d'en-tête de message de protocole de transport, en variante elle est peut être destinée à déterminer l'information de commande à partir de la zone de champ de données utiles du message de protocole de transport.
Dans une conformation de l'invention, l'unité de traitement est destinée à commander, au moyen de l'information de commande, le type de délivrance d'information audio sous la forme de données à transmettre, par exemple le volume de l'information audio à délivrer et/ou l'activation et/ou la désactivation d'effets sonores lors de la reproduction d'information audio.
Dans une variante de conformation, ou dans une conformation supplémentaire, de l'invention, l'unité de traitement est destinée à mémoriser, au moyen de l'information de commande, une partie des données à transmettre.
Ainsi, dans un exemple de réalisation de l'invention, la personne qui parle respectivement le terminal de communication émetteur, en d'autres termes le dispositif de communication émetteur (émetteur) peut influer, dans une liaison de communication établie, par exemple lors d'une conversation téléphonique, sur la délivrance d'information audio dans l'appareil de réception (en d'autres termes dans le dispositif de communication récepteur), par exemple modifier le volume et la tonalité de passages vocaux déterminés ou introduire ou supprimer des effets spéciaux tels que l'écho ou l'effet Hall. Cela peut être effectué par exemple de façon statique, c'est-à-dire pour la durée d'une conversation téléphonique, généralement pendant une liaison de communication existante, de façon constante, ou de façon dynamique, c'est-à-dire avec adaptation à des passages audio déterminés.
En outre, la personne qui parle (émetteur), en d'autres termes le dispositif de communication émetteur, peut marquer, pendant une liaison de communication établie, c'est-à-dire par exemple pendant une conversation téléphonique, des passages déterminés de sa conversation afin de manipuler séparément le récepteur dans le terminal de télécommunications, c'est-à-dire dans le dispositif de communication récepteur, (par exemple repérer le début et la fin d'un itinéraire et ordonner la mémorisation du texte se trouvant entre les repères dans le terminal du récepteur de façon à pouvoir réécouter l'itinéraire si besoin est.
L'exemple de l'introduction de signaux de commande dans un message RTP et/ou un message RTCP conformément au document [1] (respectivement comme profil ou extension de profil pour RTP/RTCP) permet d'appliquer les signaux de commande, c'est-à-dire en général l'information de commande, à différents types de Codecs, même à des Codecs développés dans le futur, pour manipuler des données en temps réel dans l'appareil de réception, et d'exploiter très avantageusement ces signaux de commande dans l'appareil de façon synchronisée.
Des exemples de réalisation de l'invention sont représentés dans les figures et sont expliqués en détail dans la suite. Les mêmes éléments ou des éléments identiques portent dans les figures les mêmes références.
La figure 1 représente un schéma d'un système de communication selon un exemple de réalisation de l'invention; la figure 2 représente un organigramme du codage et du décodage des données à transmettre selon un premier exemple de réalisation de l'invention; la figure 3 représente un organigramme du codage et du décodage des données à transmettre selon un deuxième exemple de réalisation de l'invention; la figure 4 est une représentation schématique du déroulement dans le temps de la transmission de données avec des paquets de données RTP et des paquets de données RTCP selon un exemple de réalisation de l'invention; la figure 5 représente une structure d'un paquet RTP selon un premier mode de réalisation de l'invention; la figure 6 représente la structure d'un paquet RTP selon un deuxième mode de réalisation de l'invention; la figure 7 représente la structure d'un paquet RTCP selon un troisième mode de réalisation de l'invention; la figure 8 représente la structure d'un paquet RTCP selon un quatrième mode de réalisation de l'invention; et la figure 9 représente un synoptique d'un système de communication selon un autre mode de réalisation.
La figure 1 représente un système de communication 100 selon un premier exemple de réalisation de l'invention, le système de communication étant conformé pour la communication selon une norme de communication par téléphonie mobile, par exemple une norme de communication par téléphonie mobile cellulaire, par exemple UMTS (Universal Mobile Telecommunications System), en variante selon une autre norme de communication 3GPP ou également selon GSM.
Dans la figure 1, il est représenté pour des raisons de simplicité un premier terminal de communication par téléphonie mobile 101 ainsi qu'un deuxième terminal de communication par téléphonie mobile 102. Les deux terminaux de communication par téléphonie mobile 101, 102 ont établi une liaison de communication qui est fournie par un réseau de communication par téléphonie mobile 103 par le biais d'une première interface aérienne 104 pour le premier terminal de communication par téléphonie mobile 101 respectivement une d'une deuxième interface aérienne 105 pour le deuxième terminal de communication par téléphonie mobile 102.
Chaque terminal de communication par téléphonie mobile 101, 102 comporte un microphone respectif 106 respectivement 107 destiné à l'enregistrement de signaux vocaux ainsi que des touches de commande 108 respectivement 109 et un haut-parleur respectivement 111 destiné à la reproduction de signaux acoustiques respectivement de signaux vocaux décodés ainsi qu'une unité d'affichage 112 respectivement 113 pour la représentation d'information textuelle, d'information d'image fixe respectivement d'information vidéo.
Dans la suite, sans limiter le caractère général, on part du fait que des signaux vocaux doivent être transmis du premier terminal de communication par téléphonie mobile 101 au deuxième terminal de communication par téléphonie mobile 102.
Cependant, il faut mentionner à cet égard que, dans le cadre de l'invention, on n'a pas forcément affaire à un terminal de communication par téléphonie mobile ou à un réseau de communication par téléphonie mobile. L'invention peut également être utilisé dans le cadre d'un réseau de communication fixe, lequel réseau fixe fournit des liaisons de communication avec des terminaux de communication de réseau fixe.
En ce qui concerne la transmission de signaux vocaux, on utilise dans le domaine de la téléphonie mobile par exemple le procédé de codage AMR (surtout dans un environnement réseau qui est conformé selon la norme GSM selon 3GPP (Third Generation Partnership Project) ou un QCELP 13k (surtout dans un environnement réseau qui est conformé selon la norme de communication CDMA 2000 selon 3GPP2).
Dans la suite, il est représenté un exemple de l'introduction de signaux de commande dans ce que l'on appelle le Real Time Transport Protocol (RTP) , comme décrit dans le document [ 1] . Le RTP offre plusieurs avantages dans le cadre des 30 exemples de réalisation décrit, par exemple: 1) Dans le RTP, la définition de profils pour des classes déterminées de données utiles est possible, comme par exemple le RTP Profile for Audio and Video Conferences selon le document [2]. Conformément aux exemples de réalisation de l'invention, on peut également définir un ensemble de signaux de commande comme profil ou extension de profil pour RTP.
2) RTP permet de transporter les signaux de commande indépendamment du Codec réellement utilisé.
3) Des signaux de commande transportés par RTP, comme décrit en détail dans la suite, peuvent être exploités dans le terminal de réception de façon synchronisée et être associés à des passages Codec en temps réel ainsi déterminés.
4) Le RTP selon le document [1] est un protocole de transport 10 qui n'est surtout utilisé que lorsque l'on doit transmettre des données en temps réel.
Le RTP ne permet pas d'effectuer une gestion des ressources (Ressourcemanagement) ni de garantir une qualité de service (Quality of Service (QoS)). Tout cela est réglé par d'autres couches de protocole dans le cadre de l'architecture de communication à zones de couche de protocole. En plus de RTP, il existe ce que l'on appelle le Real Time Transport Control Protocol (RTCP) qui est prévu dans une conformation de l'invention et qui permet de commander et de surveiller le transport des données. Il faut mentionner que le RTCP est optionnel, c'est-à-dire que le RTP peut également être implémenté sans RTCP dans un mode de réalisation de l'invention.
En outre, il faut mentionner que, dans une conformation de l'invention dans laquelle il n'est pas nécessaire de transmettre les données en temps réel, on peut également utilisation l'invention en utilisant HTTP comme protocole pour la réception de l'information de commande décrite dans la suite.
La figure 2 représente un organigramme 200 symbolisant pour le premier terminal de communication par téléphonie mobile 101 et le deuxième terminal de communication par téléphonie mobile 102 le processus de codage respectivement de décodage de données à coder et à transmettre 201, par exemple de données vocales, qui ont été reçues par le microphone 106 du premier terminal de communication par téléphonie mobile 101. Dans cet exemple de réalisation de l'invention, Les données à transmettre sont codées dans un Codec qui est par exemple un codeur à la source qui est destiné à coder les signaux vocaux 201 selon AMR ou QCELP 13k (Codec 202). Les données à transmettre codées à la source sont amenées à une unité de protocole de transport RTP 203 dans laquelle les données codées à la source du Codec 202 sont codées selon RTP et/ou RTCP, en option en utilisant des profils RTP 204 pour donner des paquets de données RTP et/ou des paquets de données RTCP. Comme expliqué encore en détail dans la suite, il est prévu dans les modes
de réalisation suivants de l'invention d'ajouter une information de commande 205 aux paquets de données RTP respectivement aux paquets de données RTCP.
La figure 4 représente un synoptique 400, au niveau de la couche de protocole de transport, du déroulement dans le temps de la transmission de données avec des paquets de données RTP 401 et des paquets de données RTCP 402. Il faut mentionner que les paquets de données RTP 401 et les paquets de données RTCP 402 de doivent pas forcément comporter la même quantité de données. L'agencement, comme représenté dans la figure 4, selon lequel un paquet de données RTCP 402 est à chaque fois inséré tous les cinq paquets de données RTP 401, est simplement donné à titre d'exemple et peut être modifié d'une façon quelconque dans d'autres modes de réalisation. La distance entre deux paquets de données RTCP 402 est désignée par Report Interval 403 et est indiqué habituellement en millisecondes (ms).
Le trafic de données RTP/RTCP peut se faire entre deux terminaux de télécommunications, c'est-à-dire comme représenté dans la figure 2, entre le premier terminal de communication par téléphonie mobile 101 et le deuxième terminal de communication par téléphonie mobile 102 ou en variante entre un terminal de télécommunications et une unité de réseau ayant une fonctionnalité de transmission.
Tout comme RTP, RTCP est également indépendant des couches de protocole sous-jacentes et peut être utilisé dans 5 différents environnements réseau.
La figure 2 représente un exemple de réalisation d'un modèle de couche de protocole qui repose sur le User Datagram Protocol (UDP) et le Internet Protocol (IP).
Ainsi, dans ce mode de réalisation de l'invention, les paquets de données RTP 401 et/ou les paquets de données RTCP 402 sont empaquetés, c'est-àdire codés, en paquets de données UDP au moyen d'une unité de protocole de transport UDP 206 et sont amenés à une unité de protocole IP 207 qui codent les paquets de données UDP en paquets de données IP. Les paquets de données IP sont là encore amenés à une unité de protocole à deux couches 208 dans laquelle sont réalisés par exemple le protocole de sous- couche RLC ainsi qu'un protocole de sous couche Medium Access Control.
Les paquets de données IP, codés au moyen des couches de protocole à deux couches 208, sont amenés à une couche de protocole à une couche 209, c'est-à-dire une couche de protocole physique qui établit une liaison de communication physique avec une couche de protocole physique correspondante 210 du côté du deuxième terminal de communication par téléphonie mobile 102. Les paquets de données sont transmis par la couche physique, dans l'exemple de réalisation de l'invention par l'entremise du réseau de communication par téléphonie mobile 103, au deuxième terminal de communication par téléphonie 102 où ils sont décodés conformément au protocole de la couche physique 210 et amenés à la sous-couche de protocole à deux couches 211 correspondante, également réalisés par exemple en utilisant la couche de protocole RLC et/ou une sous-couche de protocole Medium Access Control, où ils sont décodés. Les paquets de données, décodés par cette unité de couche de protocole à deux couches 211, sont amenés à une unité de couche de protocole IP 212 au moyen de laquelle les paquets de données qui lui sont amenées sont dépaquetés conformément à Internet Protocol et les paquets de données décodés de façon correspondante sont amenés à l'unité de protocole UDP 213 de laquelle les paquets de données IP sont décodés selon UDP. Les paquets de données, décodés par l'unité de protocole UDP 213, sont amenés à l'unité de protocole RTP/RTCP 214 et sont décodés par cette unité conformément à RTP et/ou RTCP, éventuellement en utilisant des profils RTP 215. Dans le cadre de ce décodage, comme expliqué encore en détail dans la suite, on extrait, en d'autres termes on détermine, l'information de commande 205 des paquets de données RTP 401 et/ou des paquets de données RTCP 402. L'information de commande est amenée à une unité de traitement 216.
En outre, les paquets de données décodés selon RTP respectivement les paquets de données décodés selon RTCP sont amenés à un décodeur à la source dans un Codec 217, situé du côté récepteur, du deuxième terminal de communication par téléphonie mobile 102 au moyen duquel on réalise un décodage à la source, par exemple selon ARM ou QCELP 13k, de façon à former des données de signaux vocaux 218 à reproduire qui sont amenés également à l'unité de traitement 216.
L'unité de traitement 216 est par exemple une mémoire ou une unité d'affichage ou le microphone 107 du deuxième terminal de communication par téléphonie mobile 102, selon le type de données à traiter.
Si, comme dans cet exemple de réalisation, les données sont des données de signaux vocaux 218, celles-ci sont alors délivrées au moyen du hautparleur 111, l'information de commande 205 étant prise en compte dans le cadre de la reproduction. Par exemple, comme expliqué en détail dans la suite, le volume ou la tonalité du signal vocal 218 peut être modifié conformément à l'information de commande ou on peut activer ou désactiver conformément à l'information de commande un effet spécial comme l'écho ou l'effet Hall.
A cet égard, il faut mentionner que l'UDP a un environnement fonctionnel relativement petit. Les applications 5 disposent d'un accès direct à la couche IP 207 sans garantir la délivrance de paquets de données et ne délivre qu'une vérification par additions de bits et une fonctionnalité de multiplexage de ports.
Dans une variante de réalisation de l'invention, il est prévu d'utiliser dans le cadre de la transmission et de la délivrance de services en temps réel le IP based Media Subsystem (IMS) décrit dans les documents [3] et [4] qui repose sur l'Internet Protocol. L'IMS peut être une Session Control and Service Delivery Plattform permettant de délivrer différentes applications et différents services multimédia destinés à des abonnés mobiles (par exemple des abonnés de téléphonie mobile), mais également à des abonnés fixes, (c'est-à-dire par exemple à des abonnés à un réseau fixe). L'utilisation de différents supports (Voix, image, texte,...) permet, en mélangeant des services de télécommunications et des services de données, d'effectuer un échange de données entre les utilisateurs (mobiles) qui présente davantage de facettes et qui est plus naturel) que dans le cas précédent.
Des domaines d'application possibles des modes de réalisation de l'invention et de IMS sont les services Instant Messaging, Presence et Push to Talk over Cellular (Poc).
L'information de commande 205, qui peut être introduite par un utilisateur par exemple au moyen des touches de commande 108 du premier terminal de télécommunications par téléphonie mobile 101, peut être de différents types et sert par exemple à commander le traitement des données utiles à transmettre 201 dans le récepteur, c'est-à-dire dans cet exemple de réalisation dans le deuxième terminal de communication par téléphonie mobile 102.
Des exemples de signaux de commande possibles 205, prévus dans différents modes de réalisation de l'invention et destinés à manipuler par exemple des données en temps réel dans un terminal de réception, c'est-à-dire dans le deuxième terminal de communication par téléphonie mobile 102, sont les suivants.
1) L'appareil de réception, c'est-à-dire le deuxième terminal de communication par téléphonie mobile 102, indique qu'il peut effectuer des effets sonores, déclenchés par l'émetteur (le premier terminal de communication par téléphonie mobile 101), lors de la transmission de données du type vidéo. Le premier terminal de communication par téléphonie mobile 101 décide d'utiliser cette fonctionnalité et influe lors de la transmission d'une séquence vidéo sur la reproduction audio dans l'appareil de réception, c'est-à-dire dans le deuxième terminal de communication par téléphonie mobile 102 (il modifie par exemple le volume ou la tonalité de passages vocaux déterminés ou ajoute temporairement des effets spéciaux comme l'écho ou l'effet Hall).
2) L'appareil de réception (c'est-à-dire par exemple le deuxième terminal de communication par téléphonie mobile 102) indique qu'il peut effectuer la mémorisation de données en temps réel, déclenchée par l'émetteur (c'est-à-dire par exemple par le premier terminal de communication par téléphonie mobile 101) lors de la transmission de données du type audio. La personne qui parle, c'est-à-dire en d'autres termes l'utilisateur du premier terminal de communication par téléphonie mobile 101, décide d'utiliser cette fonctionnalité et repère, par exemple en utilisant les touches d'entrée 108, pendant la conversation téléphonique, le début et la fin de passages particulièrement importants de sa conversation (par exemple, comme décrit ci-dessus, un itinéraire ou analogue) dans l'appareil de réception 102. Le deuxième terminal de communication par téléphonie mobile peut ecouter la conversation repérée, si besoin est, sans avoir à déclencher établir une nouvelle liaison de télécommunications avec le premier terminal de communication par téléphonie mobile 101. 3) Le deuxième terminal de communication par téléphonie mobile, généralement l'appareil de réception, indique qu'il ne peut pas généralement utiliser des signaux de commande envoyés par le premier terminal de communication par téléphonie mobile 101, généralement l'émetteur, pour manipuler des données en temps réel. Par contre, l'unité de transmission, insérée et disponible dans le réseau de communication 103, indique qu'il peut traiter des signaux de commande envoyés par l'émetteur. Les deux l'indiquent à l'émetteur et celui-ci décide de marquer maintenant, pendant la conversation téléphonique, le début et la fin de passages particulièrement importants de sa conversation en vue de la mémorisation. À la place du deuxième terminal de communication 102, l'unité de transmission, inséré dans le réseau de communication par téléphonie mobile 103, effectue la mémorisation des conversations repérées par exemple sur un serveur externe et informe le récepteur qu'il peut réécouter la conversation repérée, si besoin est, en établissant une liaison de communication avec l'unité de réseau correspondante/le serveur correspondant.
La figure 3 représente une variante de réalisation de l'invention qui est très similaire au premier mode de réalisation représenté dans la figure 2, à la différence que le système de communication 300 du deuxième exemple de réalisation de l'invention ne repose pas sur le protocole de transport UDP mais sur le protocole de transport Transmission Control Protocol (TCP) ; de plus, à la place de la couche de protocole UDP 206 de ce mode de réalisation, il est prévu une unité de protocole TCP 301 au-dessus de laquelle se trouve une unité de protocole de couche intermédiaire 302 qui reçoit les paquets de données RTP 401 respectivement les paquets de données RTCP 402 et qui les convertit en paquets de données qui peuvent être traités par l'unité de protocole TCP 301. Les paquets de données TCP sont amenés à l'unité de protocole de données IP 207.
Dans ce deuxième mode de réalisation de l'invention, il est prévu une unité de protocole TCP correspondante 303 et une unité de protocole de couche intermédiaire correspondante 304 dans le deuxième terminal de communication par téléphonie mobile 102 pour décoder de façon correspondante les paquets de données.
Étant donné que l'architecture de communication est par ailleurs la même dans les deux modes de réalisation, la description du déroulement des communications ne sera pas répétée.
Il faut mentionner que, dans le cadre des modes de réalisation de l'invention décrit dans la suite, l'émetteur, c'est-à-dire par exemple le premier terminal de communication par téléphonie mobile 101, ajoute lors de la transmission de données en temps réel les paramètres de commande, c'est-à-dire l'information de commande 205, non pas au niveau de la couche de protocole d'application mais dans le protocole de transport sous-jacent, c'est-à-dire dans une couche de protocole de transport sousjacente au Codec 202.
Dans les exemples de réalisation qui sont utilisés dans un réseau de télécommunications qui repose sur la technologie IMS, les données de commande sont transmises au niveau de la couche de protocole RTP/RTCP. Comme déjà mentionné ci-dessus, il existe deux types différents de paquets de données, un pour des paquets de données RTP et un pour des paquets de données RTCP.
Il est proposé dans la suite plusieurs solutions alternatives pour incorporer l'information de commande 205 dans des paquets de données RTP 401 ou dans des paquets de données RTCP 402; il faut mentionner que les solutions alternatives décrites dans la suite peuvent également être combinées entre elles.
La figure 5 représente un paquet de données RTP 500 dans un premier mode de réalisation de l'invention avec un nouveau type Payload.
Le Champ Type de Payload (Payload Type, PT) 501 dans la zone d'en-tête 502 du paquet de données RTP 500 permet au premier terminal de communication par téléphonie mobile 101 de signaler au récepteur, c'est-à- dire au deuxième terminal de communication par téléphonie mobile 102, quel type de données est contenu dans une zone de données Payload 503 du paquet de données RTP 500. Dans ce mode de réalisation de l'invention, il s'agit des signaux de commande (en d'autres termes de l'information de commande 205) (en anglais: Control Parameters 512). Pour effectuer ce signalement, la valeur de du champ Type de Payload 501 est mise une nouvelle valeur xy .
En outre, le paquet de données RTP comporte encore des zones de champ suivantes dans la zone d'en-tête (Header) 502, comme décrit en détail dans le document [1] de données RTP 600 dans un deuxième mode de réalisation de l'invention, les mêmes champs portant les mêmes références que dans le paquet de 30 données RTP 500 de la figure 5.
Dans le paquet de données RTP 600, il est prévu une autre modification selon laquelle l'unité émettrice signale à l'unité réceptrice, à l'aide du bit n 3 601 dans la zone d'en-tête 502 (quatrième bit depuis la gauche) que l'on a ajouté au champ de tête standard 502 du paquet de données RTP Version 504, Padding 505, Extension 506, Compteur CSRC (CC) 507, Marqueur 508, Numéros de séquence 509, Dateur automatique 510 et SSRC/CSRC 511.
6 représente un paquet É champ champ É champ - champ champ É champ champ É champ La figure un encore un autre de champ de tête 602 qui fait suite au champ de tête standard 502, en d'autres termes que le champ de tête standard 502 a été étendu par l'unité émettrice 101 d'un nouveau champ de tête 602.
Dans ce mode de réalisation, il est maintenant prévu que les paramètres de commande contiennent le nouveau champ de tête inséré 602 pour la manipulation, du côté du récepteur, des données utiles dans la partie Payload 503. Le décodage syntaxique et la sémantique de ce nouveau champ de tête défini 602 seront définis par exemple dans un profil RTP associé 204. À cet égard, il est prévu d'utiliser par exemple pour la zone de tête supplémentaire 602 dans la zone de tête RTP une structure TLV (Tag 603: le nom de champ défini de façon univoque; Length 604: la longueur du ou des valeurs de champ existantes en bits ou en octets; Value 605: la valeur de champ proprement dite).
En fonction de la définition (par exemple dans le profil RTP 204), la nouvelle zone de champ de tête 602 peut également contenir plus d'un paramètre de commande lorsque par exemple le profil RTP 204 définit de façon correspondante qu'il est possible d'imbriquer d'autres objets TLV dans la zone de champ Value 605. Dans la figure 6, les signaux de commande (c'est-à-dire l'information de commande 605) (en anglais: Control Parameters) se trouve donc dans la zone de champ Value 605 et comportent le cas échéant des objets TLV imbriqués les uns dans les autres.
La figure 7 représente un paquet de données RTCP 700 dans un premier mode de réalisation du type APP avec les extensions dans les champs, décrits dans la suite, name et subtype ainsi que Control Parameters dans la zone de champ Payload. Ainsi, il est prévu dans ce mode de réalisation de modifier le paquet de données RTCP 700 et d'incorporer l'information de commande 205 dans ce paquet de données et de le transmettre au deuxième terminal de communication par téléphonie mobile 102.
À l'aide de la quatrième entrée 701 (bit n 8 à bit n 15) dans la zone de champ de tête 702, l'unité émettrice signale à l'unité réceptrice quel type de données est contenu dans la partie Payload 703 du paquet de données RTCP 700.
Dans le présent mode de réalisation, il s'agit d'un Application Defined Packet (APP) pour lequel la valeur du champ Packet Type est mise de façon normalisée à PT = 204. On signale que l'on a affaire ici à une information de commande 205 selon l'invention pour la délivrance des données 201, au moyen du champ name 704 qui est devient associé à la valeur d'un DOCC (Data Operation Control Commands).
Le type de manipulation souhaitée par l'unité émettrice est stipulé à l'unité réceptrice par le champ subtype 505. Il pourrait être prévu par exemple pour l'effet sonore Hall le subtype = 00001 (comme mot de 5 bits), pour effet sonore Echo le subtype = 00010, etc. Pour signaler à l'appareil de réception d'autres paramètres nécessaires à un effet déterminé, on pourrait insérer à la fin du paquet de données RTCP 700 d'autres Control Parameters 706 qui peuvent alors être spécifiques au Subtype. En outre, les champs suivants sont contenus dans le paquet de données RTCP 700: - un champ Version 707, - un champ Padding 708, - une zone de champ Données de longueur 710 ainsi que 25 - une zone de champ Profile-Specific Extensions 711.
La figure 8 représente un paquet de données RTCP 800 dans un autre mode de réalisation de l'invention de type APP; dans ce mode de réalisation de l'invention, on signale à l'aide de la quatrième entrée de champ 701 (bit n 8 à n 15) dans la zone d'en-tête 702, comme déjà expliqué ci-dessus, quel type de données est contenu dans la partie Payload 703 du paquet de données 800.
Dans le présent exemple, il s'agit là encore d'un Application Defined Packet (APP), pour lequel la valeur du champ Packet Type est mise de façon normalisée à PT = 204. On constate qu'il s'agit de la transmission de propriétés d'appareils (propriétés matérielles et logicielles) de l'unité réceptrice 5 qui sont transmises de l'unité réceptrice à l'unité émettrice, avantageusement par une nouvelle valeur dans le champ name 802, comme par exemple une valeur CIRE (Capability Indication Receiving Entity).
Cependant, on utilise aussi dans ce cas éventuellement la même valeur de champ que ci-dessus, ce qui est une simple question de définition.
Le Subtype 801 sert alors à indiquer de façon plus précise une propriété utilisée du côté de la réception, par exemple subtype = 00011 représente la propriété On peut influer sur la reproduction de données audio et on peut encore insérer à la fin du paquet de données RTCP 800 une liste de Capability Indication Items 803 pour pouvoir signaler des paramètres supplémentaires nécessaires. Ces paramètres sont alors spécifiques au Subtype.
Par exemple, le subtype = 00011 ( on peut influer sur la reproduction de données audio ) peut représenter dans la liste des Capability Indication Items 803 des paramètres spécifiques à cette fonctionnalité : le volume peut être régulé sur cinq niveaux, on peut donner un effet Hall , etc. D'autres valeurs possibles sont par exemple: - la mémorisation de données en temps réel est généralement possible, - la mémorisation de données en temps réel est possible lorsqu'elle est mise en service par le récepteur, - on peut effectuer un repérage initial et des repérages 30 finaux dans le flux de données, - on peut influer sur la reproduction de données audio, le volume peut être modifié, - des effets sonores peuvent être ajoutés, on peut mettre ou retirer de la musique de fond, etc. A cet égard, il faut mentionner que la liste décrite ci-dessus est donnée simplement à titre d'exemple et peut être complétée en fonction de l'application et des besoins.
Dans une autre conformation de invention, on part du fait que le paquet de données RTCP 800 est utilisé dans ce mode de réalisation pour transmettre les propriétés permises par l'unité de réception dans une architecture de réseau dans laquelle est insérée l'unité de réseau ayant une fonctionnalité de communication des au moins deux terminaux de télécommunications 101, 102. Dans ce scénario, il est prévu que l'unité de réseau puisse extraire la liste des Capability Indication Items 803 des paquets de données RTCP reçus 800, les déclencher et les traiter et puisse adapter les flux de données à transmettre à l'unité réceptrice du côté du réseau conformément aux paramètres de commande ajoutés par l'unité émettrice dans le cas où l'unité réceptrice elle-même n'est pas en mesure de le faire et le permet.
Concrètement, l'invention permet à un émetteur d'influer de façon ciblée sur la manipulation (par exemple sur le traitement, par exemple sur la reproduction) des données en temps réel à transmettre dans l'appareil de réception. Avantageusement, les signaux de commande ne seront alors pas incorporés dans le Codec mais dans la couche de protocole de transport sous-jacente de façon à garantir une séparation nette entre le Codec et les paramètres de commande. De cette façon, l'invention peut également être appliquée d'une façon universelle à un futur Codec sans avoir à modifier le Codec lui-même.
La figure 9 représente un synoptique d'un mode de 30 réalisation dans lequel les signaux de commande sont ajoutés dans le cadre d'un Codec aux données à transmettre.
Ainsi, une possibilité de transmission de l'information de commande 901 destinée à commander un traitement, du côté du récepteur, des données en temps réel à transmettre de la source (c'est-à-dire de l'unité d'émission 902) au récepteur (c'est-à-dire l'unité de réception 903) consiste à modifier le Codec utilisé en correspondance 904 dans l'unité d'émission 902. Dans le cas où les données en temps réel sont un signal vocal qui est appliqué par exemple à un microphone 905 de l'unité d'émission, l'unité de codage 904 du côté de l'émetteur, destinée au Codec AMR déjà mentionné ci-dessus et fréquemment utilisé, pourrait par exemple comporter, en plus de l'entrée des données vocales/audio, également une entrée destinée aux signaux de commande 901 et l'unité de décodage 906 pourrait comporter du côté du récepteur, en plus de la sortie des données vocales/audio, également une sortie des signaux de commande 907.
Le Codec lui-même contient dans ce cas les signaux de commande à l'aide desquels l'unité de commande 907 représentée dans la figure 9 peut influer de façon ciblée sur la manipulation des données en temps réel à transmettre (par exemple leur reproduction ou leur traitement) dans l'appareil de réception 903, par exemple au moyen d'un haut-parleur 908 conformément aux instructions ajoutées du côté de l'émetteur (donc conformément à l'information de commande 901).
Comme représenté dans la figure 9, l'unité d'émission 902 est couplée à l'unité de réception 903 au moyen d'un réseau de communication 909.
On n'a pas affaire alors à un procédé universel, c'est-à- dire indépendant du Codec. Chaque Codec doit être modifié, ce qui impliquent des dépenses en matière de normalisation dans différents organismes de normalisation.
Dans ce document, on a cité les publications suivantes: [1] IETF: RFC 3530, RTP: A transport Protocol for Real Time Applications, http://www. ietf.org/rfc.html, juillet 2003.
[2] IETF: RFC 3551, RTP Profile for audio and video Conference with minimal Control, http://www.ietf.org/rfc.html, juillet 2003.
[3] 3GPP TS 22.228 Version 6.7.0, Release 6, Third Generation 35 Partnership Project, Technical Specification Group Services and Systems Aspects, Service Requirements for the Internet Protocol (IP Multimédia Core Network Subsystem, Stage 1, http://3gpp.org/ftp/Specs/2004-12/Rel6/22 Series/ [4] 3GPP TS 22.228 Version 6.8.0, Release 6, Third Generation Partnership Project, Technical Specification Group Services and Systems Aspects, IP Multimédia Subsystem (IMS), Stage 2, http://3gpp. org/ftp/Specs/2004-12/Rel-6/23 Series/ [5] DE 34 23 203 Al [6] US 6707819 B1
LISTE DES REFERENCES
Système de communication 101 Premier terminal de communication par téléphonie mobile 102 Deuxième terminal de communication par téléphonie mobile 103 Réseau de communication par téléphonie mobile 104 Première interface aérienne Deuxième interface aérienne 106 Microphone du premier terminal de communication par téléphonie mobile 107 Microphone du deuxième terminal de communication par téléphonie mobile 108 Touche de commande du premier terminal de communication par téléphonie mobile 109 Touche de commande du deuxième terminal de communication par téléphonie mobile Haut-parleur du premier terminal de communication par téléphonie mobile 111 Haut-parleur du deuxième terminal de communication par téléphonie mobile 112 Unité d'affichage du premier terminal de communication par téléphonie mobile 113 Unité d'affichage du deuxième terminal de communication par téléphonie mobile 200 Organigramme 201 Données 202 Codec 203 Unité de protocole RTP/RTCP 204 Profil RTP 205 Information de commande 206 Unité de protocole UDP 207 Unité de protocole IP 208 Unité de protocole RLC/MAC 209 Unité de protocole PHY 210 Unité de protocole PHY 211 Unité de protocole RLC/MAC 212 Unité de protocole IP 213 Unité de protocole UDP 214 Unité de protocole RTP/RTCP 215 Profil RTP 216 Unité de traitement 217 Codec 218 Données 300 Organigramme 301 Unité de protocole TCP 302 Unité de protocole de couche intermédiaire 303 Unité de protocole TCP 304 Unité de protocole de couche intermédiaire 25 400 Diagramme 401 Paquet de données RTP 402 Paquet de données RTCP 403 Report Interval 500 Paquet de données RTP 501 Champ Payload Type 502 En-tête 503 Champ Payload 504 Champ Version 505 Champ Padding 506 Champ Extension 507 Champ Compteur CRSC (CC) 508 Champ Marqueur 509 Champ Numéros de séquence 510 Champ Dateur 511 Champ SSRC/CSRC 512 Control Parameters 600 Paquet de données RTP 601 Bit n 3 602 Zone d'en-tête 603 Champ Tag 604 Champ Longueur 15 605 Champ Value 700 Données RTCP 701 Zone de champ PT 702 Entête 703 Champ Payload 704 Champ Name 705 Champ Subtype 706 Champ Control Parameter 707 Champ Version 25 708 Champ Padding 709 Champ Donnée de longueur 710 Champ SSRC/CSRC 711 Extensions spécifiques au profil 800 Paquet de données RTCP 801 Champ Subtype 802 Champ Name 803 List Capability Indication Items 900 Synoptique 901 Information de commande 902 Unité d'émission 903 Unité de réception 904 Unité de codage 905 Microphone 906 Unité de décodage 907 Unité de commande 908 Haut-parleur 909 Réseau de communication 10 20 25 30
Claims (16)
1. Dispositif de communication caractérisé en ce qu'il comporte -une unité de codage à la source destinée à coder à la source des données à transmettre, - une unité de protocole de transport couplée à l'unité de codage à la source et destinée à générer au moins un message de protocole de transport à partir des données codées à la source, l'unité de protocole de transport étant conçue de façon à pouvoir ajouter aux données codées à la source dans le message de protocole de transport une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport.
2. Dispositif de communication selon la revendication 1, caractérisé en ce que - l'unité de protocole de transport comporte une première 20 sousunité de protocole de transport et une deuxième sous-unité de protocole de transport - la deuxième sous-unité de protocole de transport étant destinée à former un message à partir du message formé par la première sous-unité de protocole de transport conformément au Transport Control Protocol ou au User Datagram Protocol, et - la première sous-unité de protocole de transport ayant pour but d'ajouter aux données codées à la source dans le message de protocole de transport une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport.
3. Dispositif de communication selon la revendication 2, caractérisé en ce que la première sous-unité de protocole de transport est destinée à former au moins un message à partir des données codées à la source conformément à l'un des protocoles de communication suivants: -Real Time Transport Protocol, - Real Time Transport Control Protocol, -Hypertext Transfer Protocol.
4. Dispositif de communication selon l'une des revendications 1 à 3, caractérisé en ce que les données à transmettre sont des données en temps réel.
5. Dispositif de communication selon l'une des revendications 2 à 4, caractérisé en ce qu'il comporte la première sous-unité de protocole de transport est destinée à introduire l'information de commande dans la zone d'en-tête du message de protocole de transport.
6. Dispositif de communication selon l'une des revendications 2 à 4, caractérisé en ce que la première sous-unité de protocole de transport est destinée à introduire l'information de commande dans la zone de champ de données utiles du message de protocole de transport.
7. Dispositif de communication selon l'une des revendications 1 à 6, dans lequel le type de reproduction d'informations audio peut être commandé sous forme de données à transmettre au moyen de l'information de commande.
8. Dispositif de communication selon l'une des revendications 1 à 6, caractérisé en ce que une mémorisation d'une partie des données à transmettre peut être commandée au moyen de l'information de commande.
9. Dispositif de communication caractérisé en ce qu'il comporte -une unité de protocole de transport destinée à former des 30 données codées à la source à partir d'au moins un message de protocole de transport reçu, une unité de décodage à la source couplée à l'unité de protocole de transport et destinée à décoder à la source les données codées à la source, l'unité de protocole de transport étant conçue de façon à pouvoir déterminer à partir du message de protocole de transport une information de commande permettant de commander le traitement des données codées à la source, avec une unité de traitement qui est destinée à traiter les données codées à la source conformément à l'information de commande déterminée.
10. Dispositif de communication selon la revendication 9, caractérisé en ce que - l'unité de protocole de transport comporte une première 10 sousunité de protocole de transport et une deuxième sous-unité de protocole de transport, - la deuxième sous-unité de protocole de transport étant destinée à former au moins un message pour la première sous-unité de protocole de transport à partir d'un message reçu conformément au Transport Control Protocol et au User Datagram Protocol, et - l'unité de protocole de transport étant destinée à pouvoir déterminer à partir du message de protocole de transport une information de commande permettant de commander le traitement des données codées à la source.
11. Dispositif de communication selon la revendication 10, caractérisé en ce que la première sous-unité de protocole de transport est destinée à décoder un message conformément à l'un des protocoles de communication suivants: - Real Time Transport Protocol, - Real Time Transport Control Protocol, - Hypertext Transfer Protocol.
12. Dispositif de communication selon l'une des revendications 9 à 11, caractérisé en ce que les données à transmettre sont 30 des données en temps réel.
13. Dispositif de communication selon l'une des revendications à 12, caractérisé en ce que la première sous-unité de protocole de transport est conçue de façon à pouvoir déterminer l'information de commande à partir de la zone d'en- tête du message de protocole de transport.
14 Dispositif de communication selon l'une des revendications 10 à 12, caractérisé en ce que la première sous-unité de protocole de transport est conçue de façon à pouvoir déterminer l'information de commande à partir de la zone de champ de données utiles du message de protocole de transport.
Dispositif de communication selon l'une des revendications 9 à 14, caractérisé en ce que l'unité de traitement est conçue de façon à pouvoir commander le type de reproduction d'informations audio sous la forme de données à transmettre au moyen de l'information de commande.
16. Dispositif de communication selon l'une des revendications 9 à 15, caractérisé en ce que l'unité de traitement est conçue de façon à pouvoir mémoriser une partie des données à transmettre au moyen de l'information de commande.
17. Procédé de formation d'un message de protocole de transport, caractérisé en ce que - des données à transmettre sont codées à la source, - au moins un message de protocole de transport est formé à partir des données décodées à la source conformément à un 20 protocole de transport, - dans le message de protocole de transport, il est ajouté une information de commande permettant de commander le traitement des données à transmettre dans un dispositif de communication recevant le message de protocole de transport.
18. Procédé de traitement d'un message de protocole de transport caractérisé en ce que - des données codées à la source sont générées à partir d'au moins un message de protocole de transport reçu, conformément un protocole de transport, - les données codées à la source sont codées à la source, - on détermine à partir du message de protocole de transport une information de commande permettant de commander le traitement des données codées à la source,.
- les données codées à la source sont traitées conformément à 35 l'information de commande déterminée.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102005027247A DE102005027247B4 (de) | 2005-06-13 | 2005-06-13 | Kommunikationseinrichtungen, Verfahren zum Bilden einer Transportprotokoll-Nachricht und Verfahren zum Verarbeiten einer Transportprotokoll-Nachricht |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2888698A1 true FR2888698A1 (fr) | 2007-01-19 |
| FR2888698B1 FR2888698B1 (fr) | 2011-09-02 |
Family
ID=36775562
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0605234A Expired - Fee Related FR2888698B1 (fr) | 2005-06-13 | 2006-06-13 | Dispositif de communication, procede de formation d'un message de protocole de transfort et procede de traitement d'un message de protocole de transport |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US9231814B2 (fr) |
| DE (1) | DE102005027247B4 (fr) |
| FR (1) | FR2888698B1 (fr) |
| GB (1) | GB2427523B (fr) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101523590B1 (ko) * | 2009-01-09 | 2015-05-29 | 한국전자통신연구원 | 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기 |
| US8265022B2 (en) | 2009-02-10 | 2012-09-11 | Apple Inc. | Apparatus and methods for transmission of emergency call data over wireless networks |
| JP5857661B2 (ja) * | 2011-11-18 | 2016-02-10 | 沖電気工業株式会社 | パケット処理装置及び方法 |
| CN111625244B (zh) * | 2020-05-29 | 2023-04-25 | 华畅科技(大连)股份有限公司 | 基于3gpp协议的asn.1-per动静态编解码方法 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4185169A (en) | 1977-02-04 | 1980-01-22 | Sharp Kabushiki Kaisha | Synthetic-speech calculators |
| SU663125A1 (ru) | 1977-08-19 | 1979-05-15 | Херсонский Филиал Головного Специализированного Конструкторско-Технологического Бюро Автоматизированных Систем Управления Научнопроизводственного Объединения "Система" | Громкоговор щее устройство, управл емое голосом |
| US4118604A (en) | 1977-09-06 | 1978-10-03 | Paul Yanick | Loudness contour compensated hearing aid having ganged volume, bandpass filter, and compressor control |
| US4490584A (en) | 1983-03-18 | 1984-12-25 | Controlonics Corporation | Infrared remote telephone system level control |
| DE3423203A1 (de) * | 1984-06-22 | 1986-01-02 | Jürgen 5210 Troisdorf Buss | Regelsystem |
| JPH0548489A (ja) | 1991-08-08 | 1993-02-26 | Matsushita Electric Ind Co Ltd | 電話装置 |
| IT1286478B1 (it) | 1996-12-02 | 1998-07-08 | Sgs Thomson Microelectronics | Metodo di regolazione del volume e della sensazione sonora in un dispositivo audio |
| US6359656B1 (en) * | 1996-12-20 | 2002-03-19 | Intel Corporation | In-band synchronization of data streams with audio/video streams |
| US6707819B1 (en) * | 1998-12-18 | 2004-03-16 | At&T Corp. | Method and apparatus for the encapsulation of control information in a real-time data stream |
| EP1035735A3 (fr) * | 1999-03-12 | 2007-09-05 | Kabushiki Kaisha Toshiba | Codeur et décodeur d'images animées optimisés pour la mise en oeuvre du protocole temps réel (RTP) |
| JP4945044B2 (ja) * | 2000-02-22 | 2012-06-06 | ノーテル・ネットワークス・リミテッド | 無線パケット交換音声コールを制御するためのシステムおよび方法 |
| US6970935B1 (en) * | 2000-11-01 | 2005-11-29 | International Business Machines Corporation | Conversational networking via transport, coding and control conversational protocols |
| US7145919B2 (en) | 2001-06-01 | 2006-12-05 | Telefonaktienbolaget Lm Ericsson (Publ) | Method and apparatus for transporting different classes of data bits in a payload over a radio interface |
| KR100412903B1 (ko) | 2001-12-19 | 2003-12-31 | 현대자동차주식회사 | 다이나믹 사운드 시스템 |
| US20040032859A1 (en) * | 2002-08-15 | 2004-02-19 | Miao Kai X. | Managing a remote resource |
| US20040264452A1 (en) * | 2003-06-25 | 2004-12-30 | Gaurav Mittal | Apparatus, and associated method, for embedding control information into packet formatted data |
| TWI230531B (en) * | 2003-11-04 | 2005-04-01 | Benq Corp | Local area network of controlling signal transmission and a method thereof |
| JP4513514B2 (ja) | 2004-11-10 | 2010-07-28 | 日本電気株式会社 | 多地点通話システム、携帯端末装置及びそれらに用いる音量調整方法並びにそのプログラム |
-
2005
- 2005-06-13 DE DE102005027247A patent/DE102005027247B4/de not_active Expired - Fee Related
-
2006
- 2006-06-13 GB GB0611688A patent/GB2427523B/en not_active Expired - Fee Related
- 2006-06-13 FR FR0605234A patent/FR2888698B1/fr not_active Expired - Fee Related
- 2006-06-13 US US11/423,946 patent/US9231814B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| GB2427523B (en) | 2007-12-05 |
| GB2427523A (en) | 2006-12-27 |
| GB0611688D0 (en) | 2006-07-26 |
| DE102005027247A1 (de) | 2006-12-14 |
| FR2888698B1 (fr) | 2011-09-02 |
| US20060285545A1 (en) | 2006-12-21 |
| DE102005027247B4 (de) | 2013-11-07 |
| US9231814B2 (en) | 2016-01-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9307079B2 (en) | Handling announcement media in a communication network environment | |
| US7529675B2 (en) | Conversational networking via transport, coding and control conversational protocols | |
| CA2442676C (fr) | Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets | |
| US20060094472A1 (en) | Intelligent codec selection to optimize audio transmission in wireless communications | |
| KR101065649B1 (ko) | 리던던시 관리를 제공하기 위한 시스템 및 방법 | |
| EP2105014B1 (fr) | Actions et mises en oeuvre de récepteur pour un traitement multimédia efficace | |
| US9767802B2 (en) | Methods and apparatus for conducting internet protocol telephony communications | |
| EP3692696B1 (fr) | Signalisation d'une requête d'adaptation d'une session de communication en voix sur ip | |
| CN101790754B (zh) | 用于提供amr-wb dtx同步的系统和方法 | |
| EP1944930A2 (fr) | Procédé de signalisation permettant la prise en compte de la raison de l'appel | |
| FR2888698A1 (fr) | Dispositif de communication, procede de formation d'un message de protocole de transfort et procede de traitement d'un message de protocole de transport | |
| EP1526511A1 (fr) | Terminal de téléphonie à gestion, en réception, de la qualité de restitution vocale | |
| KR101893829B1 (ko) | 데이터 변조를 통한 녹취파일의 암호화 및 복호화 방법 | |
| EP1921835A1 (fr) | Enrichissement de la signalisation dans une session de communication de type "Push to Talk" par insertion d'une carte de visite | |
| CA2922654C (fr) | Procedes et appareil de realisation de communications par telephonie sous protocole internet | |
| Pearce et al. | An architecture for seamless access to distributed multimodal services. | |
| CN112953963B (zh) | 媒体流内容加密处理系统及加密处理方法 | |
| EP2064855A1 (fr) | Procede de communication entre plusieurs terminaux | |
| KR100854883B1 (ko) | 통신 단말기 및 통신 단말기의 발신자 표시 방법 | |
| FR2930699A1 (fr) | Negociation optimisee de ressources de codage entre clients de communication | |
| WO2004100492A1 (fr) | Procede et dispositif de synchronisation de flux de donnees | |
| CN113923198A (zh) | 一种用于改善VoIP语音通话质量低的方法和装置 | |
| Zetterström | Mobile Total Conversation–Communication for All, Everywhere | |
| Lee et al. | Internet Telephony Gateway Server-Software Design |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TP | Transmission of property |
Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE Effective date: 20120228 |
|
| ST | Notification of lapse |
Effective date: 20160229 |