Brevet FR3091404A1 — publié le 20200703

Description Titre de l'invention : Procédé de traitement de messages vocaux, procédé de désactivation d'un codage DTMF et procédé de traitement d'une demande de désactivation d'un codage DTMF. Technique antérieure 100011 L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement le domaine des télécommunications en utilisant le codage DTMF (pour « Dual Tone Multi Frequency » en anglais) utilisé pour des communications entre des terminaux et des serveurs vocaux interactifs. 100021 Les codes DTMF sont généralement émis par un terminal à destination d'un serveur vocal interactif, au cours d'une communication entre le terminal et le serveur, afin de permettre à un utilisateur du terminal de sélectionner des choix proposés par le serveur et de naviguer dans une arborescence offerte par le serveur. Cependant, le serveur peut aussi émettre des codes DTMF. 100031 Le codage DTMF est historiquement utilisé pour des communications de téléphonie fixe dans les réseaux RTC (Réseau Téléphonique Commuté). Ce codage constitue un mode de signalisation d'événements (les sélections effectuées par l'utilisateur par exemple). Dans l'état de la technique, le codage DTMF est actif par défaut, quelle que soit la technologie téléphonique utilisée pour la communication entre le terminal et le serveur vocal. [0004] Pour les réseaux RTC. les codes DTMF sont transportés au cours d'un appel télé- phonique entre le terminal et le serveur vocal avec les données vocales, c'est-à-dire dans le signal audio en utilisant des fréquences spécifiques aux codes DTMF, pendant un temps d'appui de l'utilisateur du terminal sur un bouton permettant de générer un code DTMF, par exemple. [0005] Pour les réseaux mobiles commutés en circuit, de 2ème et 3ème génération (2G, 3G), les codes DTMF sont émis en dehors de la bande de communication, dans un message de signalisation. Les codes DTMF sont transportés depuis le terminal mobile jusqu'à un commutateur mobile MSC (pour « Mobile Switch Center » en anglais) qui insère ces codes DTMF avec les données vocales, dans le flux audio et commute l'appel téléphonique vers le serveur vocal. Cependant. les codes DTMF émis par le serveur sont reçus par le terminal avec les données vocales. [0006] Pour les réseaux supportant la voix sur IP, VoIP (pour « Voicc over IP »), les codes DTMF sont transportés en mode IETF RFC4733 tant que possible, sinon avec les données vocales. [0007] Dans tous les cas, le codage DTMF est par défaut actif dans le terminal, le serveur 2 vocal et tous les dispositifs intermédiaires du réseau, tels que les commutateurs, les routcurs, les équipements média d'interconnexion de réseau, connus en anglais par « Media Gateway », les équipements de type I-SBC (pour « Interconnect-Session Border Controler » en anglais), et les équipements de type NBI (pour « Nctwork Border Infrastructure » en anglais), placés en coupure de flux entre le terminal et le serveur. [0008] Comme le codage DTMF est actif par défaut, le terminal, le serveur et les dispositifs intermédiaires se mettent toujours en écoute des flux échangés pour pouvoir détecter des codes DTMF s'ils en existent. Par conséquent, lorsqu'une communication se déroule sans échange de codes DTMF, des ressources DSP (pour « Digital Signal Processing » en anglais) de traitement de signaux sont gaspillées. [0009] Un autre problème se présente lorsque le terminal ne dispose pas d'un clavier permettant de générer des codes DTMF. Dans ce cas, le terminal doit utiliser un autre moyen pour pouvoir communiquer avec le serveur vocal qui déploie le codage DTMF. A titre d'exemple, le terminal peut utiliser une technique de reconnaissance vocale qui permet de générer des codes DTMF à partir de messages vocaux, couplée à une technique de synthèse des codes DTMF. [0010] Cette solution demande beaucoup de ressources de traitement DSP et de mémoire. [0011] En plus, elle rallonge le temps de réactivité pour émettre effectivement le code DTMF vers le serveur vocal. L'expérience de l'utilisateur se dégrade si le serveur est configuré pour mettre fin à la communication au bout d'une durée déterminée et en absence de réception d'un code DTMF, ou si le serveur est configuré pour rediffuser des annonces vocales en attente de la réception d'un code DTMF. [0012] Lorsque le terminal ne dispose pas de moyens locaux pour la reconnaissance vocale (et / ou pour la synthèse de codes DTMF), il peut solliciter un dispositif spécifique qui dispose de ces moyens. Le terminal envoie des messages vocaux de l'utilisateur au dispositif, et reçoit en retour les codes DTMF à envoyer au serveur vocal. [0013] Cette solution présente en outre un inconvénient d'augmentation de la charge réseau pour les communications entre le terminal et le dispositif sollicité pour la reconnaissance vocale. [0014] En particulier, lorsque le terminal peut interpréter des commandes vocales après détection d'un message vocal déterminé, dit de réveil, l'expérience de l'utilisateur est dégradée, car l'utilisateur doit annoncer le message de réveil, puis un message vocal représentatif du code DTMF que l'utilisateur souhaite envoyer au serveur vocal. [0015] Un tel terminal peut être un assistant vocal conforme à la norme DECT et utilisant un service téléphonique VoIP (pour « Voice over Internet Protocol » en anglais) par l'intermédiaire d'un équipement de terminaison de réseau, comme l'assistant Djingo d'Orange et Deutsche Telekom (marques déposées), ou certains assistants vocaux 3 conçus pour des personnes âgées, des enfants ou des personnes malvoyantes. En effet, l'utilisateur doit annoncer le message vocal de réveil pour que le terminal interprète le prochain message vocal qu'il détecte en tant que commande. A titre d'exemple, le message de réveil d'un assistant vocal de Google (marque déposée) est « Ok Google ! » ou « Bonjour Google ! », le message de réveil d'un assistant Djingo est « Ok Djingo ! ». Ensuite, l'utilisateur doit annoncer vocalement ce qu'il souhaite envoyer au serveur vocal qui ne peut interpréter que des codes DTMF, par exemple en disant « sélectionner option 1 », le terminal doit convertir cette commande vocale en un code DTMF si ce terminal dispose localement d'un moyen de reconnaissance vocale et de synthèse de codes DTMF, sinon le terminal doit envoyer la commande vocale à un dispositif spécifique qui lui retourne le code DTMF. [0016] En plus des inconvénients déjà cités, l'utilisateur doit connaître la commande vocale qu'il doit annoncer pour qu'elle soit correctement interprétée, par exemple « option 1 » ou « 1 » ou « sélection 1 » ou « DTMF 1 ». [0017] Aussi, la prononciation du message de réveil pendant la communication entre le terminal et le serveur vocal peut révéler des informations du domaine privé à ce serveur. Par exemple, le message dc réveil «OK Djingo » révèle que Ic terminal est un assistant vocal de type Djingo et que l'utilisateur est un client de l'opérateur Orange. [0018] De plus, les messages vocaux destinés à l'assistant vocal sont reçus par le serveur car la communication est établie. Par conséquent, lorsque le serveur vocal dispose lui aussi d'un module de reconnaissance vocale, les messages vocaux adressés à l'assistant vocal peuvent déclencher des interactions de services non prévues au niveau du serveur, par exemple le serveur peut générer un message « Veuillez répéter je n'ai pas compris la commande ». [0019] 11 existe donc un besoin en une solution permettant à un terminal de communiquer avec un serveur vocal, et qui ne présente pas ces inconvénients. Exposé de l'invention [0020] L'invention vise un procédé de traitement de messages vocaux par un terminal, le procédé comprenant des étapes de: -- envoi à un serveur vocal d'une requête devant être interprétée par le serveur pour désactiver un codage DTMF sur un canal de communication entre le serveur et le terminal ; -- réception en provenance du serveur d'une donnée de configuration du terminal; -- interprétation de la donnée de configuration et application au terminal d'un mode de configuration obtenu à partir de cette interprétation ; et -- traitement des messages vocaux par le terminal selon le mode de configuration. [0021] Corrélativement, l'invention vise un système communiquant comportant un terminal, le système communiquant comprenant : -- un module de communication configure pour envoyer à un serveur vocal une requête devant être interprétée par le serveur pour désactiver un codage DTMF sur un canal de communication entre le serveur et le terminal, et pour recevoir du serveur une donnée de configuration du terminal ; et -- un module de paramétrage configure pour interpréter la donnée de configuration et pour appliquer au terminal un mode de configuration obtenu à partir de ladite interprétation, le terminal devant traiter des messages vocaux selon le mode de configuration. [0022] Les caractéristiques et avantages du procédé de traitement de messages vocaux selon l'invention présentés ci-après s'appliquent de la même façon au système communiquant selon l'invention et vice versa. [0023] L'invention permet d'adapter les communications avec les serveurs vocaux aux terminaux de nouvelles technologies, ne disposant pas forcément d'un clavier pour pouvoir générer des codes DTMF. [0024] L'invention permet à un terminal ne pouvant pas ou ne souhaitant pas utiliser le codage DTMF, de tenter de faire désactiver le codage DTMF par le serveur et d'établir une solution alternative au codage DTMF. [0025] Dans un mode de réalisation, la donnée de configuration comporte un acquittement positif de la requête pour la désactivation du codage DTMF. [0026] Ce mode permet au terminal de communiquer avec le serveur selon une méthode al- ternative au codage DTMF, cette méthode alternative pouvant être spécifiée par la donnée de configuration. [0027] Par exemple, la méthode alternative peut être une méthode de reconnaissance vocale au niveau du serveur. Le terminal applique donc un mode de configuration pour éviter la génération de codes DTMF et simplement transmettre les messages vocaux qu'il détecte au serveur. La donnée de configuration peut comporter aussi une commande au terminal pour qu'il traite les messages vocaux avant de les transmettre au serveur, sans générer des codes DTMF, par exemple une compression ou une application d'un filtre aux messages vocaux. [0028] Ce mode permet également aux dispositifs intermédiaires placés en coupure de flux entre le terminal et le serveur de savoir que le codage DTMF est désactivé sur le canal de communication entre le terminal et le serveur, et donc ne plus surveiller ce canal afin de détecter des codes DTMF. L'invention permet donc de réduire le besoin en mémoire et en ressources DSP au niveau des dispositifs intermédiaires concernés par le canal de communication entre le terminal et le serveur. [0029] Lorsque le terminal est un assistant vocal, ce mode permet une réactivité accélérée au niveau des messages émis par le terminal, celui-ci n'ayant pas besoin d'interpréter des commandes vocales ni de générer ou solliciter un dispositif pour générer des codes DTMF. [0030] Dans un mode de réalisation, la donnée de configuration comporte une commande pour que le terminal interprète pendant une durée déterminée les messages vocaux en tant que commandes vocales. [0031] Ce mode permet à un terminal de type assistant vocal de se dispenser d'une détection d'un message de réveil. La qualité d'expérience de l'utilisateur sera alors améliorée : l'utilisateur n'ayant plus besoin d'annoncer le message de réveil. En plus les données personnelles de l'utilisateur sont mieux protégées : le serveur n'entend pas le message de réveil et ne peut pas donc déduire que le terminal est un assistant vocal. [0032] Dans un mode de réalisation, la requête, envoyée au serveur vocal, est comprise dans un champ d'un message de signalisation. Ce mode permet d'envoyer cette requête indépendamment des données vocales et de façon transparente vis-à-vis de l'utilisateur du terminal. [0033] Dans un mode de réalisation, le message de signalisation est : - un message de type SIP INVITE, SIP REINVITE, SIP UPDATE, SIP 200 OK, ou SIP 1XX ; - une offre ou une réponse conforme au protocole SDP (pour « Session Description Protocol » en anglais) ; -- un entête SIP Supported ou SIP Requircd ; -- un nouveau entête SIP dédié pour transmettre ladite requête; -- un message conforme au protocole ISUP/BICC de type IAM, ACM, ANM. PRO, ou CON; ou -- une requête HTTP de demande d'établissement d'une session WebRTC. [0034] Conformément à l'état de la technique, les messages de type SIP INVITE, SIP REINVITE et SIP UPDATE sont utilisés pour une signalisation d'une communication sortante, les messages de type SIP 200 OK sont utilisés pour une signalisation d'une communication entrante, les messages de type SIP 1XX sont utilisés pour une signalisation sans prise de ligne de l'appelé, en mode dit « Early Media » en anglais, tel qu'un message de type SIP 180 Ringing ou SIP 183 In Progress. Les messages de type SIP 1XX peuvent encapsuler une offre ou une réponse conforme au protocole SDP et adaptée pour transmettre la dite requête. [0035] Plusieurs types de messages de signalisation sont envisageables. Des messages connus de l'art antérieur peuvent être exploités pour transmettre la requête. [0036] En particulier, ces messages de signalisation peuvent être utilisés indépendamment de l'invention. Il n'y a donc pas d'envoi de messages additionnels spécifiques pour l'invention. [0037] Dans un autre mode de réalisation, la requête est comprise dans une séquence en 6 DTMF. [0038] Ce mode est utile lorsque le système communiquant, conforme à l'invention, ne sait pas si le serveur dispose d'un moyen de communication alternatif au codage DTMF. Dans cc cas, le système de communication envoie la requête en tant que code DTMF car le codage DTMF est supposé être activé par défaut au niveau du serveur. [0039] Dans un autre mode de réalisation, la requête est comprise dans un message vocal pouvant être interprété par ledit serveur. [0040] Ce mode permet à l'utilisateur du terminal d'annoncer vocalement qu'il ne peut pas ou ne souhaite pas utiliser le codage DTMF. Alternativement, le message vocal comportant la requête peut être généré automatiquement par le système communiquant conforme à l'invention. Ce mode nécessite que le serveur dispose d'un moyen pour interpréter le message vocal, par exemple un moyen de reconnaissance vocale. [0041] Dans un mode de réalisation, l'envoi de la requête n'est effectué que si on détermine que le terminal ne dispose pas d'un clavier permettant de générer des codes DTMF. [0042] Ce mode est particulièrement intéressant lorsque le système communiquant conforme à l'invention, mettant en oeuvre le procédé de l'invention, comporte plusieurs terminaux. Le système communiquant peut demander la désactivation du codage DTMF uniquement pour les terminaux ne disposant pas d'un clavier pour générer des codes en DTMF, les autres terminaux ayant des claviers et peuvent communiquer avec le serveur vocal en utilisant le codage DTMF. [0043] Dans un mode de réalisation, le système communiquant comporte une base conforme à la norme DECT et l'étape de détermination que le terminal ne dispose pas d'un clavier peut être mise en oeuvre par la base. [0044] En particulier, la base DECT peut être intégrée dans un équipement de terminaison de réseau, un tel équipement connu en France sous le nom de « box » tel qu'un équipement LiveBox (produit commercialisé d'Orange, marque déposée). Autrement, la base n'est pas intégrée à l'équipement de terminaison de réseau mais elle est connectée à un port numérique ou analogique de cet équipement. [0045] Dans un mode de réalisation, la détermination que le terminal ne dispose pas d'un clavier est obtenue à partir d'un message reçu du terminal. Ce message pouvant être un message de type ACCESS-RIGTHS-REQUEST d'appairage du terminal avec la base, ou un message émis après l'appairage, tel qu'un message de type CC-FACILTY, MMIWU ou CC-INFO. [0046] Des messages connus de l'art antérieur peuvent alors être utilisés pour transmettre une information indiquant que le terminal ne dispose pas de clavier permettant de générer des codes DTMF. En particulier, ces messages peuvent être envoyés indépendamment de l'invention, il n'y a donc pas d'envoi de messages en plus spécifiques pour l'invention. 7 [0047] Dans un mode de réalisation où la base est comprise dans un équipement de ter- minaison de réseau, la détermination que le terminal ne dispose pas de clavier permettant de générer des codes DTMF est obtenue par lecture d'une donnée de configuration de cet équipement. [0048] En configurant l'équipement de terminaison de réseau, l'utilisateur peut configurcr aussi la base et préciser les terminaux qui ne disposent pas de clavier. [0049] L'invention vise également un procédé de désactivation d'un codage DTMF sur un canal de communication entre un serveur vocal et un terminal, le procédé étant mis en oeuvre par le serveur et comprenant des étapes de: - réception d'une requête devant être interprétée par le serveur pour désactiver le codage DTMF sur le canal ; - activation pour le canal d'une solution alternative pour communiquer avec le terminal, à la place du codage DTMF ; et - envoi au terminal d'une donnée de configuration comportant un acquittement positif de la requête. [0050] Corrélativement, l'invention vise un premier serveur vocal connecté à un terminal via un canal de communication et pouvant communiquer avec ledit terminal par un codage DTMF, ce premier serveur comprenant : - un module de communication configuré pour recevoir une requête devant être interprétée par ledit serveur pour désactiver le codage DTMF sur le canal ; et - un module de paramétrage configuré pour activer pour le canal une solution alternative pour communiquer avec le terminal, à la place du codage DTMF, le module de communication étant configuré pour envoyer au terminal une donnée de configuration comportant un acquittement positif de la requête. [0051] Les caractéristiques et avantages du procédé de traitement de messages vocaux par un terminal selon l'invention s'appliquent de la même façon au procédé de désactivation d'un codage DTMF selon l'invention et vice versa. [0052] Les caractéristiques et avantages du procédé de désactivation d'un codage DTMF selon l'invention présentés ci-après s'appliquent de la même façon au premier serveur selon l'invention et vice versa. [0053] Comme expliqué précédemment, l'invention permet à un terminal ne souhaitant pas ou ne pouvant pas communiquer avec le serveur en utilisant le codage DTMF (notamment car il ne dispose pas d'un clavier), d'utiliser la solution alternative proposée par le serveur. La désactivation du codage DTMF sur le canal permet de réduire le temps de transit et le besoin en ressources DSP, car les dispositifs intermédiaires concernés par le canal n'auront plus besoin d'être en mode de détection de codes DTMF. [0054] Dans un mode de réalisation, la solution alternative comporte une technique de re- 8 connaissance vocale en réception et une technique de synthèse vocale en émission. [0055] L'invention vise également un procédé de traitement d'une demande de désactivation d'un codage DTMF sur un canal de communication entre un serveur vocal et un terminal, ce procédé étant mis en oeuvre par le serveur et comprenant des étapes de: - réception d'une requête devant être interprétée par le serveur pour désactiver le codage DTMF sur le canal ; - maintien du codage DTMF; - envoi au terminal d'un acquittement négatif de la requête et / ou d'une donnée de configuration comportant une commande pour que le terminal interprète pendant une durée déterminée des messages vocaux détectés par ledit terminal en tant que commandes vocales. [0056] Corrélativement, l'invention vise un deuxième serveur vocal connecté à un terminal via un canal de communication et pouvant communiquer avec le terminal par un codage DTMF, ce deuxième serveur comprenant : - un module de communication configure pour recevoir une requête devant être interprétée par ce serveur pour désactiver le codage DTMF sur le canal ; et - un module de paramétrage configure pour maintenir le codage DTMF; le module de communication étant configure pour envoyer au terminal un acquittement négatif de ladite requête et / ou une donnée de configuration comportant une commande pour que le terminal interprète pendant une durée déterminée des messages vocaux détectés par le terminal en tant que commandes vocales. [0057] L'acquittement négatif est traité par le terminal comme une donnée de configuration. Dans la suite de la description, on utilisera de façon équivalente les expressions acquittement négatif » et « donnée de configuration comportant un acquittement négatif ». [0058] Les caractéristiques et avantages du procédé de traitement de messages vocaux par un terminal selon l'invention s'appliquent de la même façon au procédé de traitement d'une demande de désactivation d'un codage DTMF selon l'invention et vice versa. [0059] Les caractéristiques et avantages du procédé de traitement d'une demande de désac- tivation d'un codage DTMF selon l'invention présentés ci-après s'appliquent de la même façon au deuxième serveur selon l'invention et vice versa. [0060] Le deuxième serveur peut ne pas disposer d'une solution alternative au codage DTMF. Lorsque le terminal est un assistant vocal, la donnée de configuration permet à l'utilisateur du terminal de se dispenser d'annoncer le message de réveil, et donc d'améliorer la qualité de son expérience. [0061] Dans un mode de réalisation, l'envoi de la donnée de configuration comportant la commande pour que le terminal interprète les messages vocaux en tant que commandes et optionnel, et le fait pour le terminal de recevoir l'acquittement négatif suffit pour 9 que cc terminal interprète les messages vocaux détectés pendant une durée déterminée en tant que commandes. [0062] L'invention vise également un premier système de communication comportant un système communicant conforme à l'invention et un premier serveur conforme à l' invention. [0063] L'invention vise également un deuxième système de communication comportant un système communicant conforme à l'invention et un deuxième serveur conforme à l' invention. [0064] L'invention vise également un premier programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou un dispositif d'un système communiquant conforme à l'invention, tel que le terminal ou une base DECT ou un équipement de terminaison de réseau. Cc programme comporte des instructions adaptées à la mise en oeuvre d'un procédé de traitement de messages vocaux par un terminal conforme à l'invention, tel que décrit ci-dessus. [0065] L'invention vise également un deuxième programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou un premier serveur conforme à l'invention. Cc programme comporte des instructions adaptées à la mise en oeuvre d'un procédé de désactivation d'un codage DTMF conforme à l'invention, tel que décrit ci-dessus. [0066] L'invention vise également un troisième programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou un deuxième serveur conforme à l'invention. Ce programme comporte des instructions adaptées à la mise en oeuvre d'un procédé de traitement d'une demande de désactivation d'un codage DTMF conforme à l'invention, tel que décrit ci-dessus. [0067] Chacun de ces programmes 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. [0068] L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions du premier, du deuxième ou du troisième programme d'ordinateur tel que mentionné ci-dessus. [0069] Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent 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 disc) ou un disque dur, ou une mémoire flash. [0070] D'autre part, les supports d'information ou d'enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. [0071] Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. [0072] Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés conformes à l' invention. Brève description des dessins [0073] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : [fig.1] la figure I illustre une architecture d'un réseau comportant un système com- muniquant et un serveur vocal conformes à un mode de réalisation de l'invention ; [fig.21 la figure 2 illustre une architecture d'un réseau comportant un système com- muniquant et un serveur vocal conformes à un autre mode de réalisation de l' invention ; [fig.3] la figure 3 est un organigramme représentant des étapes d'un procédé de traitement de messages vocaux, et des étapes d'un procédé de désactivation d'un codage DTMF selon un mode de réalisation, les procédés étant conformes à l'invention; [fig.4] la figure 4 est un organigramme représentant des étapes d'un procédé de traitement de messages vocaux, et des étapes d'un procédé de traitement d'une demande de désac- tivation d'un codage DTMF selon un mode de réalisation, les procédés étant conformes à l' invention; [fig.51 la figure 5 est un organigramme représentmit une étape de détermination qu'un terminal ne dispose pas de clavier, selon un premier mode de réalisation ; [fig.6] la figure 6 est un organigramme représentmit une étape de détermination qu'un terminal ne dispose pas de clavier, selon un deuxième mode de réalisation ; [fig.7] la figure 7 est un organigramme représentmit une étape de détermination qu'un 11 terminal ne dispose pas de clavier, selon un troisième mode de réalisation ; Ifig.81 la figure 8 présente des architectures fonctionnelles d'un système de communication comportant un système communiquant et un premier serveur conformes à l'invention, selon un mode de réalisation de l'invention; Ifig.91 la figure 9 présente des architectures fonctionnelles d'un système de communication comportant un système communiquant et un deuxième serveur conformes à l'invention, selon un autre mode de réalisation de l'invention; et Ifig.101 la figure 10 présente des architectures matérielles d'un système communiquant, d'un premier et d'un deuxième serveur vocal selon un mode de réalisation de l'invention. Description des modes de réalisation [0074] La figure I illustre une architecture d'un réseau comportant un système com- muniquant USR, un premier serveur vocal SRV I et un deuxième serveur vocal SRV2, le système USR et les serveurs SRV I et SRV2 étant tous conformes à un mode de réalisation dc l'invention. [0075[ Le système USR comporte un terminal T et une base B conformes à la norme DECT. La base B est intégrée dans un équipement de terminaison de réseau BX. Cet équipement BX permet de connecter le système USR à un réseau coeur WAN. [0076[ Dans ce mode de réalisation, le terminal T est un assistant vocal, ne disposant pas d'un clavier permettant de générer des codes DTMF. Ce terminal T peut interpréter des messages vocaux en tant que commandes vocales, sur détection d'un message de réveil MCmd, par exemple « ok Djingo ! ». Le terminal T ne dispose pas de moyens de reconnaissance vocale. Pour interpréter les commandes vocales, ce terminal T communique avec un dispositif BCK dédié pour mettre en oeuvre une méthode de reconnaissance vocale pour des assistants vocaux, comme le terminal T. Le terminal T envoie les commandes vocales qu'il détecte à ce dispositif BCK et reçoit en retour des commandes d'envoi de codes DTMF correspondants à ces commandes. [0077] Dans ce mode, le serveur SRV1 comporte un codeur-décodeur DTMF, et des moyens pour appliquer une solution alternative au codage DTMF, telle qu'une méthode de reconnaissance vocale en réception, et une méthode de synthèse vocale en émission. [0078] Dans le mode décrit ici, le serveur SRV2 ne dispose pas de moyens pour appliquer une solution alternative au codage DTMF. [0079] Le terminal T et la base B disposent chacun d'un circuit intégré (chipset) pour com- muniquer selon la norme DECT via un canal conforme à cette nonne DECT. [0080] L'équipement BX comporte une pile protocole SIP pour communiquer avec des dis- 12 positifs ou des serveurs du réseau coeur WAN. L'équipement BX peut comporter en outre un circuit intégré et un port analogique de type FXS pour connecter un terminal analogique T2. [0081] La figure 2 illustre une architecture d'un réseau comportant un système com- muniquant USR, un premier serveur vocal SRV1 et un deuxième serveur vocal SRV2, le système USR et les serveurs SRV1 et SRV2 étant tous conformes à un mode de réalisation de l'invention. Cc mode de réalisation diffère du mode de la figure 1 en ce que la hase B n'est pas intégrée dans l'équipement de terminaison de réseau BX, mais connectée à un port de type FXS de l'équipement BX. [0082] La figure 3 est un organigramme représentant des étapes d'un procédé de traitement de messages vocaux par un terminal, conforme à l'invention, mis en oeuvre par le système communiquant USR, conforme à l'invention, en référence aux étapes E100, El 10, El 12, El 20, El 20, El 22 et El 32 décrites ci-après. L'organigramme de la figure 3 représente également des étapes d'un procédé de désactivation d'un codage DTMF, conforme à l'invention, mis en oeuvre par le serveur SRV1, conforme à l'invention, en référence aux étapes E114, El 16, El 18 et El 34 décrites ci-après. [0083] Selon le mode décrit ici, les procédés de l'invention peuvent être mises en oeuvre dans un réseau dont l'architecture est illustrée par la figure 1 ou par la figure 2. [0084] Nous supposons ici que le terminal T est déjà appairé avec la hase B. [0085] Au cours d'une étape E100, la hase B détermine que le terminal T ne dispose pas de clavier permettant de générer des codes DTMF. Cette étape E100 sera décrite en détails ultérieurement en référence aux figures 5 à 7. [0086] Au cours d'une étape E102, le terminal T détecte le message de réveil MCmd, il se configure alors pour interpréter le prochain message vocal détecté en tant que commande vocale. [0087] Au cours d'une étape E104, le terminal reçoit un message vocal MVoc I et le considère en tant que commande vocale. Le terminal T sollicite le dispositif BCK pour lui demander d'interpréter la commande vocale. Au cours de l'étape E104, le terminal T envoie le message vocal MVocl au dispositif BCK, dans un message de type HTTP Put » pal- exemple. [0088] Ce dispositif BCK reçoit au cours d'une étape E106 le message vocal, interprète que ce message comporte une commande pour émettre un appel vers le serveur SRVI, et renvoie en retour, au terminal T, une commande pour appeler le serveur SRV1. Cette commande est envoyée dans un message de type « HTTP 200 0k» par exemple, avec un paramètre de type « XMS : call ». [0089] Au cours d'une étape E108, le terminal reçoit cette commande et déclenche une com- munication sortante vers le serveur SRV1. [0090] Conformément à l'état de la technique, le terminal envoie un message de type 13 « CC-Setup » à la hase B pour émettre la communication sortante. La base B acquitte ce message par un message de type « CC-Can-Processing ». [0091] Au cours d'une étape El 10, la base B envoie à la couche protocolaire SIP de l'équipement BX, un message de type CLL, après avoir inséré une requête DMD devant être interprétée par le serveur SRVI pour désactiver un codage DTMF sur le canal de communication entre le serveur SRVI et le terminal T. Dans cet exemple, la requête DMD comporte une information indiquant que le terminal T ne dispose pas de clavier. [0092] Au cours d'une étape El 12, la couche protocolaire SIP de l'équipement BX émet un message de signalisation, de type « SIP INVITE », comportant la requête DMD, vers le serveur SRV1. [0093] Au cours d'une étape El 14, le serveur SRV1 reçoit ce message de signalisation, extrait la requête DMD. [0094] Au cours d'une étape El 16, le serveur SRV1 active la solution dc reconnaissance vocale pour le terminal T. à la place du codage DTMF. [0095] Au cours d'une étape El 18, le serveur SRV1 envoie un message de signalisation dc type « SIP 200 OK» comportant une donnée de configuration i-Confl dans ce message. Cc message de signalisation permet d'informer le terminal T que le serveur SRVI accepte de recevoir la communication émise par le terminal T, mais aussi, grâce à la donnée i-Confl, d'acquitter positivement la demande de désactivation du codage DTMF sur le canal connectant le serveur SRVI au terminal T. [0096] La couche protocolaire SIP de l'équipement BX reçoit ce message de signalisation au cours d'une étape E120 et le transmet à la base B. qui à son tour, envoie au terminal T un message de type CC-Connect, après avoir inséré la donnée de configuration i-Confl dans ce message. [0097] Le terminal T reçoit la donnée de configuration i-Confl, au cours d'une étape E120', interprète au cours d'une étape E122 la donnée de configuration i-Confl en tant qu'une commande pour désactiver le codage DTMF, et applique au cours de l'étape E122 un mode de configuration dans lequel il désactive le codage DTMF. [0098] En parallèle, suite à la réception du message de type SIP 200 OK, l'équipement BX envoie au cours d'une étape E124 un acquittement au serveur SRVI. A la réception E126 de cet acquittement, le serveur SRVI désactive le codage DTMF pour le terminal T. [0099] A la fin des étapes E122 et E126 de désactivation du codage DTMF par le terminal T et le serveur SRVI, un canal de communication est établi entre eux sans codage DTMF, mais en se basant sur la solution alternative proposée par le serveur SRV1. Des dispositifs du réseau WAN en coupure de flux entre le terminal T et le serveur SRVI auront connaissance par la lecture des messages de type SIP 200 OK (E118, E120) et / 14 ou son acquittement (E124, E126), que cc canal n'utilise pas le codage DTMF et désactivent alors l'écoute sur ce canal de codes DTMF. [0100] Au cours d'une étape El 28, le serveur SRV1 envoie au terminal T un flux de données, pour lui proposer plusieurs options de navigation dans une hiérarchie de service, par exemple ce flux de données comporte un message vocal: "dites 1 ou commercial pour joindre un agent commercial, dites 2 ou technique pour joindre le service technique". [0101] Conformément à l'état de la technique, ce flux de données est transféré du serveur SRV1 via le réseau WAN vers la pile SIP de l'équipement BX, puis de celui-ci, via la base B, vers le terminal T. Le terminal T reçoit ce flux de données au cours d'une étape E130. [0102] Au cours d'une étape E132, le terminal T détecte un message vocal MVoc2 de l'utilisateur, par exemple "1" ou "commercial". Conformément au mode appliqué au cours de l'étape El 22, le terminal T envoie ce message vocal MVoc2 au serveur SRV1 de manière standard dans le flux téléphonique. [0103] Le serveur SRV1 reçoit le message vocal MVoc2 au cours d'une étape E134, l'interprète via sa solution de reconnaissance vocale et déduit qu'il s'agit d'une sélection de la première option. [0104] Au cours d'une étape El 36, le serveur SRV1 envoie un second flux de données au terminal T, en tenant compte de l'interprétation du message MVoc2. Ce second flux peut être un message vocal déroulant un menu de type "pour une nouvelle commande, dites 1 ou nouvelle; pour une commande en cours, dites 2 ou en cours, pour une réclamation, dites 3 ou réclamation...". [0105] La figure 4 est un organigramme représentant des étapes d'un procédé de traitement de messages vocaux par un terminal, conforme à l'invention, mis en oeuvre par le système communiquant USR, conforme à l'invention, en référence aux étapes E100, E110, E112, E120, E120', E222, E234, E236 et E238 décrites ci-après. L'organigramme de la figure 4 représente également des étapes d'un procédé de traitement d'une demande de désactivation d'un codage DTMF, conforme à l'invention, mis en oeuvre par le serveur SRV2, conforme à l'invention, en référence aux étapes E114, E216, E218 et E232 décrites ci-après. [0106] Selon le mode décrit ici, les procédés de l'invention peuvent être mis en oeuvre dans un réseau dont l'architecture est illustrée par la figure 1 ou par la figure 2. [0107] Nous supposons ici que le terminal T est déjà appairé avec la base B. [0108] Dans le mode décrit ici, les procédés comportent des étapes E100 à E114 mises en oeuvre par le système communicant USR, le dispositif BCK et le serveur SRV2, similaires aux étapes E100 à E114 décrites en référence à la figure 3, mises en oeuvre par le système USR, le dispositif BCK et le serveur SRV1. [0109] Suite à la réception El 14 de la demande DMD, le serveur SRV2 ne disposant pas de solution alternative au codage DTMF, maintient au cours d'une étape E216 le codage DTMF. [0110] Au cours d'une étape E218, le serveur SRV2 envoie un message de signalisation de type « SIP 200 OK» tout en insérant une donnée de configuration i-Conf2 dans ce message. Ce message de signalisation permet d'informer le terminal T que le serveur SRV2 accepte de recevoir la communication émise par le terminal T, mais aussi de transmettre la donnée i-Conf2. Cette donnée i-Conf2 comporte un acquittement négatif de la demande DMD de désactivation du codage DTMF sur le canal connectant le serveur SRV2 au terminal T. [0111] Au cours d'étapes El 20 et El 20', similaires aux étapes El 20 et El 20' décrites en référence à la figure 3, la couche protocolaire SIP de l'équipement BX reçoit ce message de signalisation et le terminal T reçoit la donnée de configuration i-Conf2. [0112] Au cours d'une étape E222, le terminal T interprète la donnée de configuration i- Conf2, et applique un mode de configuration dans lequel il maintient le codage DTMF actif. [0113] En parallèle, suite à la réception du message de type SIP 200 OK, l'équipement BX envoie au cours d'une étape E124 un acquittement au serveur SRV2. À la réception E226 de cet acquittement, un canal de communication est établi entre le terminal T et le serveur SRV2, cc canal utilise le codage DTMF. [0114] Au cours d'une étape E128, similaire à l'étape E128 décrite en référence à la figure 3, le serveur SRV2 envoie au terminal T un flux de données, pour lui proposer plusieurs options de navigation dans une hiérarchie de son service, par exemple ce flux de données comporte un message vocal: "tapez 1 pour joindre un agent commercial, tapez 2 pour joindre le service technique". [0115] Le terminal T reçoit ce flux de données au cours d'une étape E130. [0116] Au cours d'une étape E232, le serveur SRV2 envoie au terminal T un message M comportant une donnée de configuration iConf3. Cette donnée iConf3 comporte une commande pour que le terminal T interprète pendant une durée déterminée des messages vocaux détectés par ce terminal T en tant que commandes vocales. [0117] Le terminal T reçoit le message M et extrait la donnée de configuration iConf3 partir de ce message au cours d'une étape E234. [0118] Au cours d'une étape E236, le terminal T interprète la donnée iConf3 et applique un mode de configuration pour interpréter les prochains messages vocaux détectés, pendant la durée déterminée, en tant que commandes vocales. Le terminal T n'aura plus besoin de détecter le message de réveil MCmd pour passer à ce mode d'interprétation de commandes vocales. [0119] Au cours d'une étape E238, le terminal T détecte un message vocal MVoc2 "1". 16 Conformément au mode appliqué au cours de l'étape E236, le terminal T interprète le message vocal MVoc2 en tant que commande vocale et l'envoie au dispositif spécifique BCK dans un message de type HTTP Put. Dans un mode de réalisation particulier, le terminal T préfixe vocalement le message vocal MVoc2 transmis au dispositif BCK avec un message vocal « DTMF » de sorte que le dispositif BCK reçoive un message vocal « DTMF 1 » alors que l'utilisateur du terminal T n'a prononcé que « 1 ». [0120] De façon similaire à l'étape E106, le dispositif BCK interprète au cours d'une étape E240 la commande vocale MVoc2 et envoie en retour au terminal T, dans un message de type HTTP 200 OK, une commande pour que le terminal T génère un code DTMF [0121] Le terminal T reçoit cette commande au cours d'une étape E242, et envoie au serveur SRV2 le code DTMF "1" au cours d'une étape E244. [0122] Au cours d'une étape E246, la pile SIP de l'équipement BX insère ce code DTMF dans un message de type RTP RFC4733 avant de le transmettre au serveur SRV2. [0123] Le serveur SRV2 reçoit ce message vocal et extrait le code DTMF au cours d'une étape E248, et déduit qu'il s'agit d'une sélection de la première option, le service commercial. [0124] Nous supposons que la durée précisée par la donnée de configuration iConf3 expire au cours d'une étape E250. Au cours de cette étape E250, le terminal T applique son mode de configuration par défaut, pour n'interpréter des messages vocaux en tant que commandes que sur la détection du message de réveil MCmd. [0125] La figure 5 illustre un exemple de mise en oeuvre de l'étape E100 de détemaination par la base B que le terminal T ne dispose pas d'un clavier pour générer des codes DTMF, selon un mode de réalisation de l'invention. [0126] Dans cet exemple, l'étape E100 est mise en oeuvre au cours de l'appairage du terminal T sur la base B. Ce mode peut être mis en oeuvre dans un réseau dont l'architecture correspond à celle illustrée par la figure 1 ou par la figure 2. [0127] Au cours d'une étape E500, le terminal T demande à la base des droits d'accès, en lui envoyant un message de type ACCESS-RIGHTS-REQ, conforme à la norme DECT, sauf que conformément à la présente invention, ce message est modifié pour insérer une information « NoKeyboard » indiquant que le terminal T ne dispose pas de clavier. [0128] La base B reçoit cette information au cours de l'étape E100. Cette étape E100, comprise dans la phase d'appairage, est suivie par des échanges de messages d'appairage conformes à la norme DECT. [0129] La figure 6 illustre un exemple de mise en oeuvre de l'étape E100 de détemaination par la base B que le terminal T ne dispose pas d'un clavier permettant de générer des codes DTMF, selon un autre mode de réalisation de l'invention. 17 [0130] Dans le mode décrit ici, le terminal T est déjà appairé sur la base B. Ce mode peut être mis en oeuvre dans un réseau dont l'architecture correspond à celle illustrée par la figure 1 ou par la figure 2. [0131] Le terminal T envoie au cours d'une étape E600 un message MSG de type CC- FACILITY, connu de la norme DECT, mais en le modifiant par une insertion, dans un champ « Escape to Proprictary » de ce message, d'une information « NoKeyboard » indiquant que le terminal T ne dispose pas de clavier. [0132] La base B reçoit ce message MSG au cours de l'étape E100. [0133] Alternativement, au cours de l'étape E600, le terminal T envoie à la base B un message MSG de type MM-IWU, en insérant l'information « NoKeyboard» dans un champ « Escape to Proprictary » ou dans un champ « IWU-IWU » de cc message MSG. [0134] Alternativement, au cours d'une signalisation d'une communication entrante, et au cours de l'étape E600, le terminal T envoie à la base B un message MSG de type CCInfo, en insérant l'information « NoKeyboard» dans un champ « Escape to Proprictary » de ce message. Ce message MSG de type CC-Info peut être envoyé par le terminal T après une réception d'un message CC-Setup et avant ou après l'envoi d'un message CC-Alerting, par exemple. [0135] Alternativement, au cours d'une signalisation d'une communication sortante, et au cours de l'étape E600, le terminal T envoie à la base B un message MSG de type CCInfo, en insérant l'information « NoKeyboard» dans un champ « Escape to Proprietary » de ce message. Ce message MSG de type CC-Info peut être envoyé par le terminal T après une réception d'un message CC-Call Proceeding, par exemple. [0136] La figure 7 illustre un exemple de mise en oeuvre de l'étape E100 de détermination par la base B que le terminal T ne dispose pas d'un clavier permettant de générer des codes DTMF, selon un autre mode de réalisation de l'invention. [0137] Dans le mode décrit ici, le terminal T est déjà appairé sur la base B. Ce mode peut être mis en oeuvre dans un réseau dont l'architecture correspond à celle illustrée par la figure 1 où la base B est comprise dans un équipement BX de terminaison de réseau. [0138] L'équipement BX reçoit au cours d'une étape E700 des données de configuration CFG d'un dispositif D de configuration. [0139] Etant donné que la base B fait partie de l'équipement BX, les données CFG comportent en outre des données de configuration CFG' qui concernent la base B. [0140] A tire d'exemple, un utilisateur du terminal T peut sélectionner via le dispositif D, un paramètre de configuration indiquant que son terminal T ne dispose pas de clavier. Le dispositif D peut également être un serveur réseau de configuration de l'équipement BX. [0141] En particulier, même si le terminal T dispose d'un clavier, un utilisateur qui souhaite 18 désactiver le codage DTMF pour améliorer son expérience et éviter l'annonce du message de réveil MCmd, peut insérer une fausse information indiquant que son terminal T ne dispose pas de clavier. [0142] L'équipement BX extrait de ses propres données de configuration CFG, les données CFG' concernant la base et les envoie à la base B. Au cours d'une étape E100, la base B reçoit ses données de configuration CFG'. [0143] Par lecture des données CFG', la base B détermine que le terminal T ne dispose pas de clavier. [0144] Autres modes de réalisation: [0145] Dans un autre mode de réalisation, le terminal T dispose de sa propre pile pro- tocolaire SIP, le système communiquant USR conforme à l'invention ne comporte que ce terminal T et les étapes décrites précédemment mises en oeuvre par la base B ou par la pile SIP de l'équipement BX sont mises en oeuvre par le terminal T. [0146] Dans un mode de réalisation, la requête DMD est comprise dans un message de si- gnalisation de type SIP INVITE, SIP REINVITE, SIP UPDATE, SIP 200 OK, ou SIP 1XX, ou dans une offre ou une demande conforme au protocole SDP, ou dans un entête SIP Supportcd ou SIP Required ou dans un nouveau entête SIP dédié pour transmettre ladite requête DMD. [0147] Dans un mode de réalisation, la requête DMD est comprise dans un message conforme au protocole ISUP/BICC de type IAM, ACM, ANM, PRG, ou CON. [0148] Dans un mode de réalisation, la requête DMD est comprise dans une requête HTTP de demande d'établissement d'une session WebRTC. [0149] Dans un mode de réalisation, le terminal T envoie au serveur SRVI ou au serveur SRV2 une séquence en DTMF comportant la requête DMD. [0150] Dans un mode de réalisation, le terminal T envoie au serveur SRVI un message vocal comportant la requête DMD, ce serveur SRVI disposant de moyens de reconnaissance vocale pour interpréter le message vocal. [0151] Dans un mode de réalisation, lorsque le terminal T reçoit (E120') du serveur SRV2 la donnée de configuration iCont2 comportant l'acquittement négatif de la requête DMD, ce terminal T interprète les messages vocaux qu'il détecte pendant une durée déterminée en tant que commandes vocales. Dans ce mode, l'envoi (E232) par le serveur SRV2 de la donnée de configuration iConf3 est optionnel. [0152] La figure 8 représente des architectures fonctionnelles, selon un mode de réalisation de l'invention, d'un système SYSI de communication, du système communiquant USR comportant le terminal T et du serveur vocal SRVI, tous conformes à l'invention. [0153] La figure 9 représente des architectures fonctionnelles, selon un mode de réalisation de l'invention, d'un système SYS2 de communication, du système communiquant USR comportant le terminal T et du serveur vocal SRV2, tous conformes à l'invention. 19 [0154] Le système SYS1 comporte le système communiquant USR et le serveur SRV1. [0155] Le système SYS2 comporte le système communiquant USR et le serveur SRV2. [0156] Le système communiquant USR conforme à l'invention comporte au moins le terminal T. Dans les modes décrits en référence aux figures 3 et 4, le système communiquant USR comporte en outre la base B et l'équipement BX. [0157] Le système communiquant USR comporte : - un module de communication COM-USR configuré pour envoyer au serveur vocal SRV1 (ou SRV2) la requête DMD devant être interprétée par ce serveur pour désactiver le codage DTMF sur un canal de communication entre cc serveur SRV1 (ou SRV2) et le terminal T. et pour recevoir de ce serveur SRV1 (ou SRV2) la donnée de configuration, iConfl , (ou iConf2 et / ou iConf3) du terminal T; et - un module de paramétrage PRM-T configuré pour interpréter la donnée de configuration iConfl , (ou iConf2 et / ou iConf3) et pour appliquer au terminal T un mode de configuration obtenu à partir de l'interprétation, le terminal T devant traiter des messages vocaux selon ce mode de configuration. [0158] Le serveur vocal SRV1 comporte : -- un module de communication COM-1 configuré pour recevoir la requête DMD devant être interprétée par le serveur pour désactiver le codage DTMF sur le canal qui connecte ce serveur SRV1 au terminal T; et -- un module de paramétrage PRM-1 configuré pour activer pour ledit canal une solution alternative pour communiquer avec le terminal T, à la place dudit codage DTMF, le module de communication COM-1 étant configuré pour envoyer au terminal T la donnée de configuration iConf1 comportant un acquittement positif de la requête DMD. [0159] Le serveur vocal SRV2 est connecté au terminal T via un canal de communication et pouvant communiquer avec le terminal T par un codage DTMF, le serveur SRV2 comprend: -- un module de communication COM-2 configuré pour recevoir la requête DMD devant être interprétée par le serveur SRV2 pour désactiver le codage DTMF sur ledit canal ; et -- un module de paramétrage PRM-2 configuré pour maintenir le codage DTMF, le module de communication COM-2 étant configuré pour envoyer au terminal T la donnée de configuration iCont2 comportant un acquittement négatif de la requête DMD et la donnée de configuration iConf3 comportant une commande pour que le terminal T interprète pendant une durée déterminée des messages vocaux détectés par ce terminal en tant que commandes vocales. [0160] Dans le mode de réalisation décrit ici, le système communiquant USR, le serveur SRVI et le serveur SRV2 ont chacun l'architecture matérielle d'un ordinateur, telle qu'illustrée à la figure 10. [0161] Chacune des architectures du système communiquant USR et des serveurs SRV1 et SRV2 comprend notamment un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. [0162] La mémoire morte 9 du système USR selon l'invention constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur ProgT conforme à l'invention. [0163] La mémoire morte 9 du serveur SRV1 selon l'invention constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur ProgS1 conforme à l'invention. [0164] La mémoire morte 9 du serveur SRV2 selon l'invention constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur ProgS2 conforme à l'invention. [0165] La mémoire 10 du système communiquant USR permet d'enregistrer des variables utilisées pour l'exécution des étapes du procédé de traitement de messages vocaux selon l'invention, telles que la requête DMD, les données de configuration iConfl, iConf2 et iConf3, le message de réveil MCmd et les messages vocaux détectés MVocl et MVoc2. [0166] La mémoire 10 du serveur SRV1 permet d'enregistrer des variables utilisées pour l'exécution des étapes du procédé de désactivation d'un codage DTMF sur un canal selon l'invention, telles que la requête DMD et la donnée de configuration iConfl. [0167] La mémoire 10 du serveur SRV2 permet d'enregistrer des variables utilisées pour l'exécution des étapes du procédé de traitement d'une demande de désactivation d'un codage DTMF sur un canal selon l'invention, telles que la requête DMD et les données de configuration iCont2 et iConf3. [0168] Le programme d'ordinateur ProgT définit des modules fonctionnels et logiciels ici, configurés pour traiter des messages vocaux par le terminal T. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 du système USR cités précédemment. [0169] Le programme d'ordinateur ProgS1 définit des modules fonctionnels et logiciels ici, configurés pour désactiver un codage DTMF par le serveur SRV1. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 du serveur SRV1 cités précédemment. [0170] Le programme d'ordinateur ProgS2 définit des modules fonctionnels et logiciels ici, configurés pour traiter par le serveur SRV2 une demande de désactivation d'un codage DTMF. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments 21 matériels 7-11 du serveur SRV2 cités précédemment.